Lem has a (quite simple still) Git/hg/fossil interactive mode (interactive rebase is there but no reword for instance) and org-mode support is coming (https://github.com/mahmoodsh36/organ-mode).
Lem now is ncurses + webview (+ the non-longer maintained SDL2 backend) and it has daily multi-platform binaries. Try it out!
/usr/lib64/gio/modules/libdconfsettings.so: undefined symbol: g_assertion_message_cmpint
Failed to load module: /usr/lib64/gio/modules/libdconfsettings.so
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
- Solid LSP support
- Project scoped buffer switching/searching
- Great vim keybinding support (this seems to have improved since last I tried lem years ago)
- Tree-sitter support for the languages I care about.
All in all, a big improvement from a few years ago when I last tried it!
> you will want to support font fallback, input methods and screen readers, all of which require interacting with platform specific APIs and are thus much less customizable
May I ask the heretical question why of these two situations:
(a) you have one editor that makes compromises between extensibility and accessibility
(b) you have one non-accessible editor that goes all-in on extensibility, and one not-fully customizable editor that goes all-in on accessibility
one would prefer (a) over (b)? Situation (a) sounds like strictly more total effort for a worse outcome, as you have one much more complex system that tries to navigate both purposes.
[1] https://github.com/blakemcbride/common-lisp-3
[2] https://github.com/lassik/compact-lisp
[3] https://coalton-lang.github.io/
[4] https://lispcookbook.github.io/cl-cookbook/pattern_matching....
I suggest to have a look at CIEL: https://github.com/ciel-lang/CIEL/
-> CL, with batteries out of the box: http, json, csv, DB, functional data structures, regexp, pattern matching, missing docstrings, missing functions, easy script runner…
and to Epsilon: https://github.com/jbouwman/epsilon/
> Epsilon is a Lisp programming environment built using SBCL that provides functional data structures and some encoding, cryptographic hashing and network programming capabilities.
> 1. The function and variable namespaces have been collapsed into a single namespace.
Lisp-N, package system and homoiconic macro is a local optimum (IMO practically much better than Scheme, but I digress) for variable capture issue in metaprogramming. Now it's saying let's bring back the footguns and also you have to write lst instead of list. Please, no.
> 2. ...adds a layer on top of CLOS
How about a library? Why a new standard?
> 3. Common Lisp 3 supports case-sensitive symbols.
This I can relate.
> 4. Common Lisp 3 supports native threads. > 5. Common Lisp 3 supports tail recursion elimination.
Practically not a problem for today's CL. There's nothing to fix.
> Meanwhile proper typing should be introduced out of the box, like in Coalton[3], for example.
Are you saying Coalton as an embedded language should be introduced out of the box? I'm afraid it may quickly earn similar reputation as LOOP and FORMAT. Or are you saying the whole language should adopt Coalton-like typed semantics? Then I don't think it's even possible for large part of the language, especially when you take interactivity into account. What happens when a function gets redefined with different type? Worse, how about CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
> Also, pattern matching should be the part of the language, not some external library [4].
Why not? Common Lisp as a living and extensible language now evolves by adopting de-facto standard (trivia for pattern matching, bt for native threads, usocket for network, ASDF for build system, etc). Why need a committee or other form of authority to prescribe what everyone gets to use when we have a maximally democratic process?
Not the whole language as is but proper algebraic types at least. Just like most modern languages do.
> Why not? Common Lisp as a living and extensible language now evolves by adopting de-facto standard (trivia for pattern matching, bt for native threads, usocket for network, ASDF for build system, etc). Why need a committee or other form of authority to prescribe what everyone gets to use when we have a maximally democratic process?
Totally a valid point but then something like Compact Lisp proposal to strip the language to the bare minimum and extract everything out in libraries would make way more sense than the huge and only half-used CL standard we have now.
In the same way that non-hygienic macros in a Lisp-2 with a CL-style package system are a local optimum, many non-obvious design choices in the Common Lisp type system and CLOS make SLIME "just work" in almost every case.
Generally, contemporary folks that propose improvements to the CL spec tend to be misinformed / misguided and/or lacking experience to realize why their proposed improvements are bad ideas.