Almost all the comments here are about things that really possible to do in current Emacs i.e. 'feature-requests' and not "fundamental pitfalls of this foundational application". For me, it would be just:
- Redesigned with concurrency in mind.
- Common Lisp, Scheme, or anything else other than Elisp. [Just the same way Neovim adapted Lua instead of VimScript]
Someone created lem [0] which is basically an Emacs in Common Lisp. I don't know for concurrency but I hope it is designed to do so. Also there isn't org-mode.
There have been several recreations of Emacs in Common Lisp over the years, including Hemlock, CEDAR, and Climacs. They never catch on, because they’re not compatible enough with the existing base of emacs lisp software. This also applies to Scheme, although it did get closer to compatibility once or twice.
This is also closely tied to why emacs hasn’t been made much more parallelized - fundamentally, the design of emacs is too close to “a giant ball of global state”, mirroring an early Lisp Machine. It’s a high hill to design around, and it will violate basic assumptions made by most medium-plus interesting elisp code.
Do not let this dissuade you from trying! It would be a great if difficult accomplishment!
I enjoy using Lem sometimes, but mostly use Emacs. Lem is a very cool idea, and with Roswell it is easy to install and manage.
All that said, it seems like Emacs has been improving rapidly the last few years: native compilation of Elisp, LSP support, good integrations with LLMs.
More than org-mode, it needs a Texinfo viewer. Once you can access SBCL's documentation (and internal docs), now you have an almost complete Common Lisp editor with the basic features from Emacs.
Hard agree that these are true ‘fundamental pitfalls’ of Emacs’ design. However I may go further on your third point. I would like to see a dedicated new user/learner mode that in addition to saner defaults would be pretty fully configured and pre-loaded with the most common extensions/plug-ins/etc. This could then lead to development of dedicated documentation/tutorials that assist the new user in becoming proficient in the common style/habits of Emacs usage.
This could provide a much simpler full featured ‘base’ state for the app, that can then be customized from that point or can be stripped back by removing the more common add-ons and customized from the ground up.
It would in some ways necessitate a strongly opinionated set of defaults and an additional focus on documentation, but I think in the long run the app would benefit from higher retention.
I’m on the strong opinion that most highly configurable software should come with strongly opinionated defaults. “It’s infinitely configurable so you can do anything you want” is just… so annoying. You could implement an LLM using punchcards if you were mad enough. The thing that makes a tool effective is the fact that it constrains and specializes.
I'm against that. Some random user would use Org-Mode and it wouldn't need any IDE related extensions. Also, another programmer might just use Org-Babel and code in Common Lisp with org-babel and a REPL doing literary programming. Another one would use Emacs for IRC, Email and math with M-x calc and/or iMaxima and AucTex.
- Redesigned with concurrency in mind.
- Common Lisp, Scheme, or anything else other than Elisp. [Just the same way Neovim adapted Lua instead of VimScript]
- More sane defaults for new users.