I'd make cursors be positioned within the document instead of on the screen. Currently, Emacs does not support off-screen cursors. If you attempt to scroll a cursor off screen, it will move within the document to stay on screen. This behavior is contrary to all modern text editors, and there is no good workaround. I once made a serious effort to start using Emacs, but ultimately stopped because of the annoying cursor behavior. (There were other annoyances, but none so fundamental and unfixable.)

I don't care that much about the implementation, but I would like to see an emacs environment with:

- instant startup

- blazingly fast scrolling

- minimal keypress-to-display latency

I have written a lot of elisp (and had to deal with with buffer variables, dynamic scope, etc.), but aligning with modern scheme or lisp (if it can be kept compact and efficient) probably makes sense at this point. (Current emacs should provide backward compatibility as needed.)

Since so many people use emacs as an IDE, I think having an official emacs co-project/subproject focusing on a standard, extensible IDE framework (perhaps for other apps as well) would make sense.

It still seems like a pain to display graphics in emacs in various terminal apps. This should be easy, fast, and standardized.

As others have noted, supply chain attacks against open source are rampant, so vetting and sandboxing packages seems to be more important now.

Let us write plugins in whatever programming language we want and provide some simple interface like Unix sockets or something for us to communicate with the editor process.

Instead of making the first class installable extensions plugins create a primitive called modes that encapsulate groups of plugins with extra configurations so that instead of having to pick every plugins for our setup we just pick the most popular javascript or ruby etc. mode and then add a couple of our own plugins on top.

Add some system that suggests hotkeys based on usage. If I hit l 20 times instead of just hitting f’ to get to the end of the line show a popup. Gamify the key maps and suggest key maps and features even from my plugins.

Instead of having a package manager for your editor just use homebrew and integrate it deeply into the editor.

Instead of using ctrl and meta modifiers, use a leader key like escape or semicolon or comma or some such thing as the prefix key for key bindings. In fact, this desire for leader-key-based, non-modal text editing led me to write devil-mode for Emacs: <https://susam.github.io/devil/>.

The core should be in rust, verfied in lean, and the runtime should be in guile. Literate programming in org-mode should be a hard requirement. Package management should require patch algebra. Macros should be submitted to a leaderboard in a blockchain and yield flair in EUDC. M-x measure-beard-length should require 10000 hours of logged usage and unlock the major mode infinity-categorization.

Tongue-no-longer-in-cheek:

I reckon the C core of Emacs is some of the most battle-hardened code out there. Verification, a-la SEL4, is probably irrelevant but still nice. Guile is modern and performant but Elisp is still its own little joy. Literate programming is always nice until it gets in the way. Straight is good enough for me now. Macros are always cool and a leaderboard would be fun, but patch algebra is really nice, see jujutsu nowadays. And beard length is gendered and so only partially admissable. Infinity categories are way out there and always good for a reference.

create an efficient async api for plugins. it’s kind of a kernel+apps situation. an extensible editor has to have a scripted plugin system, and they should be hosted by a core that is fast, can preempt plugins, and provides “ipc” btw plugins for advanced functionality.

- Use Common Lisp instead of Emacs Lisp.

- Design a more modular architecture to make it easier to extend and maintain different components.

- Design a more robust plugin system for development and distribution of extensions.

- Implement better sandboxing and security measures for extensions.

- Better APIs for extension developers.

- better multi-threading support baked into the editor.

Biggest issue w/ emacs is once you start adding packages everything is half-broken. Ideal emacs replacement would preserve the ease of extension and flexibility but have more of a static time verification systems (types and ...?) to prevent bugs (and bonus, make easier to achieve speed too).

Allow for user controllable window layout within the frame, objectively the editor's only significant drawback.

I would probably just implement vscode but for the terminal. Emacs shortcuts already work by default in vscode for the most part.

Support prettier typography (if the user is not interacting with Emacs through a terminal, in which case of course the typography is up to the terminal-emulation app). If text in Emacs looked as pretty as text on the web does, it would be less of a struggle for me to stay focused on the Emacs text. (Text on the web was already much above average in pleasantness to look at and to read in the 1990s.)

Get rid of any keybinding or UI convention that is there because that is the way they did it the AI Lab in 1967. Make the UI as familiar to the average computer user as possible (but keep the general design of a large rectangle of text) by using mainstream conventions (which come mainly from the Mac and Windows) for how to respond to this or that keypress or to clicking or dragging with this or that mouse button.

Inside Emacs is a cross-platform toolkit (where the platforms are MacOS, other Unix derivatives, Windows and the terminal) I would split Emacs into 2 projects: a toolkit and an app that uses the toolkit. That way, if someone wants to create an "standalone" org-mode app, Magit app or Gemini browser designed to appeal to people who do not want to spend any time learning to use Emacs the app or "Emacs the generalized interface to information", they have a straightforward way to do so. (These "standalone" apps that are as easy to learn as any other GUI app will I hope help popularize the Emacs ecosystem.)

One thing I definitely would not change is I would not make Emacs dependent on or closely integrated with a browser engine.

I would change the development platform. Doing everything by mail makes things more difficult for people that are not used to the older mail+patch workflow. Having something like GitLab or sourcehut would be nice, as it would also bring a more modern bug tracker.

Personally I find following email conversations much harder than just a single conversation thread like in a GitHub issue, for example.

Scheme instead of ELISP. Concurrency (Async IO would do).

Nothing

Use python instead of lisp.

Emacs is fine, but buggy as hell.

Their version of Lisp is clearly not suited for any large-scale development. (This trickles down hard into user experience, i.e., lack of parallelism or multithreading.)

A modern display engine.

> If you were rewriting Emacs from scratch, what would you do differently?

UI: Electron, of course.

Json to represent the edit buffer in RAM. Each utf8 code point base64 encoded, in a json array, it itself, as a blob, base64 encoded. Now, before you complain that that is gonna blow up the data too much, don’t forget that 1. “Ram is cheap” and 2. “gzipped base64 is about the same size as binary”. So, of course, we’ll gzip the data in RAM.

Plugins should be JavaScript, as should be self-evident. And you’ll need a few installations of python (both 2 and 3) and node.js (each in its own docker container, obviously) to glue it all together and provide reproduceability.

With some care and work, it’ll run even on a modest machine taking up merely 60GB of disk, 32GB of RAM, a 4090ti GPU, and 8 CPU cores.

It is 2024, after all. One must use modern tools and technologies.

Build it on top of Guile.

Write Vim instead. /s

[flagged]

Not using lisp

Not using Lisp would be helpful