- More customizable than emacs
- more mature community and 'giants to stand on' (like packages)
- Stronger expected lifespan
- Realistic enough to actually commit to (not like, build the universe, build your OS from scratch)
I'd love to hear if there's anything you've found beyond the Mariana Trench! Will
- Lem is written in Common Lisp. It's less of a niche language than ELisp. You are therefore likely to find a larger library ecosystem.
- RMS didn't really like CL when he wrote Emacs. But CL is arguably a much better language today. For example, you don't need to worry about dynamic scoping.
- Lem is written entirely in CL, without any C core like Emacs does. That possibly makes Lem customizable to a deeper level than Emacs.
- Being a very young project, Lem is likely more optimized for multithreading compared to Emacs. Emacs multithreading is not up to expectations, perhaps due to legacy plugins and code.
Lem is not capable of competing with Emacs on any other points on account of the huge difference in their ages. Lem has much fewer extensions and a much smaller community. I don't know the project well enough to comment about their longetivity. But it's worth a look.
Packages: https://melpa.org/#/
Lifespan: Emacs hails from the 70s and is actively maintained.
For example, I’ve tried really hard to just change the background color of the echo area, and it appears to just not be possible without editing the C code. If possible I’d also love to be able to disable the echo area, and just check Messages directly when needed.
Whereas in Neovim you have plugins like noice.nvim that even removes the equivalent of the echo area completely, and shows messages in pop up windows instead. I don’t like that UI either, but it shows the flexibility.
In Neovim you can't redefine fundamental commands (like how self-insert-command works) or modify core behaviors with great granularity — in Elisp you can redefine one given aspect of a function without reimplementing the entire function. Or what about live introspection and modification of the running editor?
Yes, the echo area has limitations due to its C implementation, but using this edge case to claim "Emacs UI is the hardest to customize" ignores that Emacs lets you rewrite practically everything else - including replacing entire subsystems like completion, windowing, or even turning it into a completely different application.
I’m picking that point because the parent poster is asking what OP wanted to customize in Emacs and couldn’t. Well, I wanted to customize the echo area, because I find it noisy and distracting, and couldn’t. There are lots of other minor UI annoyances like this – like how the TUI version has a black square in the bottom-right corner that you can only get rid of by changing your terminal background color or editing C code. Or how you can’t, AFAIK, disable line truncation markers if you disable the fringe (the best you can do is to put whitespace characters in the corresponding display char table, but that still takes up one char width at the edge).
Some UI things that are customizable are also needlessly hard to change. For example, I really dislike when major modes or themes decide to change font sizes in section headings or add styling like italics. Hunting down and disabling such settings in each package individually is tiring, and my workaround of looping over every face and disabling those font properties – and affixing load-theme to do this automatically after changes – feels overly complex for such a simple problem. In Sublime Text, for another example, there’s a global font setting to just disable italics completely (or any other font attribute you dislike), and many terminals have simple toggles for this as well. Look also at the workarounds Rougier had to do to manage some of his feats, compared to say what one could easily do by customizing the UI of Atom/Pulsar.
Emacs is overall great, but the UI customization is the least flexible part of it, IMHO.
I think Emacs is a good example of the Lindy Effect. It's going to continue being alive for a long time because it's already been alive for a long time.
Emacs is more than enough, you do need more than 1 app.
Let's think of some hypothetical (close to practical) scenario example. Let's say I need a retrieval of fully-qualified name for a function at point.
In Emacs, I can start prototyping advising function in a scratch buffer changing the behavior of lsp--symbol-information (or related) function. I can try it out right there. I can easily debug, profile, enable and disable this feature without ever having to restart Emacs. Hell, I wouldn't even have to save it — it's all dynamic, all in-place, it's like playing a videogame.
In Neovim, I'd have to create/modify a Lua file. Find the right LSP handler to override. Write the override function. Reload the editor (losing my state), or source the file. There's no easy way to temporarily test without affecting my config. Sure, one can use Fennel for replicating REPL-driven development, but that still be limited compared to Emacs — no advice system; can't easily revert (no advice-remove like stuff); limited introspection; scope issues — need to manage original function references manually; harder discovery — no describe-function like stuff.
In VSCode to get something like that you'd need to create an entire extension project; write typescript/javascript; compile the extension; install it in VSCode; sometime reload VSCode; debug through the extension host; there's no "just try something" way.
Joyride is a game-changer for VSCode — one can use Clojure-based scripting directly, making it almost Emacs-like, yet still — no advising, can't change editor's core internals — they are not exposed to you, there's no true runtime modification of core behaviors.
So no, VSCode and Neovim do not meet the OP's criteria.