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

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]

- More sane defaults for new users.

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.)

One thing about Emacs, is it's not really just an editor anymore. Comparing it to other editors kind of misses the mark. It's more like an integrated Lisp development and runtime environment. It reminds me of Smalltalk environments, say Squeak or Pharo, albeit in a very text oriented way.

The world could probably make room for an integrated Lisp development environment that makes GUI programming more of a first class citizen. Maybe something like Medley Interlisp?

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.

- 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.

> 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.

Every key press should be passed through an LLM, to add some intelligence to the editor. The user will, of course, supply a ChatGPT api key when they register for their mandatory myNewEmacs.ai account that they’ll need to subscribe to the editor for only the cost of a few lattes a month.

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

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.

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/>.

I have actually done some work on a rewrite of the Emacs core in rust[1], so I have thought a lot about this question. Most of the things you would want to change could be fairly easily added to the existing Emacs. The biggest ones that are hard to do with the current core is concurrency and collaborative editing. My particular core is focused on concurrency[2].

Unlike a lot of commenters here, I am trying to stay backwards compatible with elisp. It is not the best, but huge body of existing code is one of the strengths of Emacs. Unlike vimscript, elisp isn’t painful enough to be worth replacing.

[1] https://coredumped.dev/2021/10/21/building-an-emacs-lisp-vm-...

[2] https://coredumped.dev/2022/05/19/a-vision-of-a-multi-thread...

1. I would like higher-level datatypes for key abstractions, such as

(1.1) Marks -> StableRegions

- reference specified text within a buffer

- continue to reference same text despite insertions or deletions

(1.2) Strings & characters -> StringBuffers

- lightweight immutable buffers (no branches or versions)

- able to hold any content a subset of a buffer can hold

- could be StableRegions of an Arena Buffer

(1.3) AbstractBuffers

- immutable buffers + a tree of deltas

- some special delta types for, e.g. indentation

- AbstractBuffers support transactions and versioning

- can support collaborative editing

- specific versions can be written to textfiles

- all versions can be stored in git or in relational database

2. Use WebAssembly instead of a specific programming language.

- This was the vision for Guile.

  - Scheme one of several languages.
  - ELisp supported but Emacs port efforts keep failing!

- The Racket ecosystem has captured this pretty well - if only it supported ELisp!

3. Prefer languages at least as simple as Scheme, but with monotonic semantics!

Non-mutable operations would appear as transactions appearing as branches/versions.

An editing session would automatically follow the latest transaction in the current branch.

Concurrent edits of the same "file" create different branches as with git, et al.

4. Separate monolithic Emacs process into SessionProcesses, DisplayProcesses and WorkerProcesses.

Multiple DisplayProcesses would allow for tightly-coupled collaborative editing. A WorkerProcess would interface buffers with processes, files, git repositories, etc. on a specific account@host giving functionality like Tramp. A user would start with one DisplayProcess connected to a SessionProcess. A SessionProcess would provide the interface between DisplayProcesses, WorkerProcesses and any co-SessionProcesses of collaborators. WorkerProcesses could be scripted without any other overhead.

I'd really prefer for emacs' implementation language to have been a lisp-1 rather than a lisp-2. It's annoying to have to do different things to treat a function as a value (put it into a list, assign it to a variable, etc.), as opposed to all other kinds of data. Any benefit you get from allowing name collisions (i.e. function named f, related but distinct variable also named f) seems very small in all elisp code I've seen and promotes confusion more than it enables desirable programming patterns.

I'd make lexical scope the default and dynamic scope opt-in on a per-variable basis. This one is probably less controversial. I think the devs are moving in that direction (e.g. by changing emacs core code to use lexical scope and adding warnings for code that doesn't opt into it), but I don't see how they will actually be able to change the default without breaking a whole bunch of user code.

Emacs is the shittiest tool I’ve been using since 1992 and will use till I die.

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.

I'd start with the core TECO editor I've written in Free Pascal[1].

Free Pascal does gigabyte strings you don't even have to allocate. Then I'd read the Emacs manual, and start writing code and tweaking TECO to make it all impedance match better.

But I'm old and weird, so maybe not the best way to get there.

[1] https://github.com/mikewarot/teco

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.

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).

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.

I like emacs for its flexibility and its ability to be a platform for people to build just about any extension. So for this you'd need a solid scripting language. I was never sold on Lisp but it's fine. I'd prefer to see lua; it just makes more sense.

The repo-reference stuff works pretty well all things considered. If it were python it would be hell.

Crazy side of me would like to see it fully written in a safe(r) language like rust, swift or zig. Basically your config would be a recompiled subsystem, loaded at runtime, or you'd recompile the whole editor.

It wouldn't hurt if the config had a bit more structure. Forcing people to set fonts etc. BEFORE loading other things; essentially enforcing an order in which things get loaded. It can get hairy after years of working in emacs.

I love that it's keyboard driven and I'd keep that for sure.

The config should automatically be a git repository and any change should generate a meaningful commit (thinking out loud).

Better key handling and none c-x nonsense. Switching between keyboard combos and straight up shortcut should be a defined choice not overwritten by x. Every 'plugins' should expose their shortcuts override clearly. Have sane defaults that aren't 30 years of cruft. This means you'd have to consider running on mac just as well as windows, and in and out of the terminal makes this extremely tricky.

Better plugin system and discovery. Often the best and only way to find how to solve a problem in emacs was by finding some random gray-beard post on some forum by sheer luck.

There's something about it where it doesn't feel quite right when using the mouse as a GUI app. Compare it to something like Sublime Text. I can't quite describe it exactly. It just feels off. It feels like you are supposed to use the keyboard shortcuts to navigate around, and the mouse is sort of bolted on secondarily or something. So I would try to make it feel more like a modern GUI app, where using the mouse feels right.

Disclaimer: my experience with Emacs is limited. I've only used it because it's the path of least resistence to learn Lisp.

So for me it would be: everything that makes Lisp programming easier, like:

- Use a Lisp implementation that's not tied to the editor.

- Slime/Sly + Quicklisp functionality out of the box.

- Integrated syntax awareness, preferably "syntax directed" for programming.

There is more, but it'll be obvious (like updated defaults and looks) unless you want to make an outright clone, or at least a direct replacement option, I wonder if that's what you mean: "rewriting Emacs" seems to suggest it is.

It's difficult. These big old projects like Emacs, and Lisp itself, have both succeeded and failed. There are features that made them last decades and others that made them stop attracting new users. How to capture the appealing parts without reproducing the quirks?

First of all, I would make sure that it would not be swapping constantly when running on eight megabytes!

It’s interesting the divide we see here between particular implementation choices, and very general design principles. FWIW I think this exposes some of the tensions in Emacs’ design itself. The fact that everything is customisable is both great and the source of many problems, and it depends on which direction you want to go how you want to move that particular needle.

I’m not totally sure what I’d do. The semantics of multithreaded or async alteration of buffers are not easy and so, even though they would be great in many ways, might make simple customisation just too painful.

More to the point, emacs already has been rewritten substantially. There’s the initial rewrite from TECO to lisp, there’s the 80s implementations like uemacs (famously used by Linus), we had a major fork with xemacs in the 90s, there’s guile emacs (ready any day now), lem is almost but not quite a Common Lisp emacs, and it’s been making a lot of progress recently. So go ahead with your rewrite, you’re in fine company!

I wish it were built with a very small, minimal core, that was just the TUI with the lisp machine like functionality, scriptable using R7RS scheme instead of elisp. And then everything else is built on top in a more modular fashion, with "battery packs" that install many modular components into one higher level functionality, like an IDE.

I'd like to eventually write something like this, there are a lot of things it would enable that you just can't do with emacs. It would be an emacs killer if implemented well, but it would also open up a whole new set of possibilities.

I don't know how far I'd get just working on it on my free time, which is competing for time with other projects. I'm looking for funding for these sorts of projects. If anyone reading this is an investor and interested in funding this sort of thing, please reach out.

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

>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.

This needs dedicated Prominenz

- throw away c language mode and and rewrite it from scratch

- make dired more usable like a normal file manager. opening a file with the associated program that would persist after emacs closes should be its primary feature. ideally i want something like a mix of ranger/lf with dired

- make it have fully-featured terminal, not dumb terminal. make it easy to open lots of terminal windows. add a way to change terminal directory with fido or dired

- make working with ssh not so horribly laggy

Concurrency, concurrency, concurrency.

And scripting with JS/TypeScript. Kind of like emacs-ng attempted (https://github.com/emacs-ng/emacs-ng/)

This will fall to the curse of most people answering didn't write emacs.

That is, rewrites can work sometimes. You typically need someone who was involved in the last two for it to work, though.

If you haven't written it once, you have no real idea on any compromises that were made.

If you haven't tried to do it without a compromise, you don't know which compromises were unexpectedly vital.

I would use Python as the extension language since it is omnipresent. ELisp has lots of terrible misfeatures that makes building large software in it difficult. I would also add better support for the services model. E.g., rather than adding spell-checking and syntax-highlighting modes you could defer those tasks to LSP servers.

Take a look at the Mac editor Alpha. It is arguably emacs-in-tcl and did a very nice job of balancing cua-style keybindings with emacs-style. Better, if I remember correctly, than things like cua-mode. It’s been literally decades since I’ve used it though, and it might be impossible to square that circle in a way that’s really frictionless.

A modern display engine.

The main quality I remember Emacs having compared to something like VSCode is its ease of extendability - but I don't know how to balance the liveness/messyness of a personal Emacs setup and wanting to package some of those bits to third parties. I think its a tension there...

I think others have hinted at it, but for me any foundational application must be written in a statically typed language, but cannot be C nor C++ /me glares at Chromium

The bad news is that I don't currently have enough free energy to help the remacs nor emacs-ng projects, but I am glad they exist

I would 1. Make it more capable as a full GUI - currently I have trouble displaying jupyter notebooks with images/progress bars etc in it. 2. Make an 'emacs app store' where you can get paid plugins (I'm going for Cursor). 3. Make collaborative editing possible.

I would use a more mainstream dynamic language like python or lua rather than emacs lisp. It has to be dynamic and maintain the flavor of repl-driven development (the whole point of emacs is that it’s one big X repl where today X is emacs lisp). It doesn’t have to be a lisp though.

Many of the non-sarcastic responses here are subjective changes (scripting language, core plugins, alternative control schemes) that will change what Emacs is for other people.

But I think we can find a lot of agreement around launch speeds, latency, typography and similar.

Instead of making it just an elisp interpreter, make it a generic platform where you can interpret any language and have them with together.

Make it Programming Language Macros, PLMACS. Kind of life a POSIXs standard. Or the Truffle framework.

I’d keep the possibility to use the ide both in the console as well as in a graphical environment for sure.

I’m not sure i’d change the scripting language, despite all of its shortcomings it has proven itself way more than enough.

Maybe better concurrency?

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.

Improve performance handling large files and large numbers of buffers. Emacs has been my daily driver for the last 10+ years and yeah perf could use some help. Everything else is superb.

is it me or is emacs just incredibly slow on machines which have endpoint security installed? O/c it's not emacs' fault directly, but all the compiling and loading in of small files really hurts the cold start scenario.

So I wish the compilation would just be done once in somebody else's pipeline not in every client.

Use Common Lisp instead of making its own mac-lisp like dialect.

Rendering performance is still my main gripe and the one most mentioned by vim users I unsuccessfully tried to convert through evil mode.

Build it with emacs

Static typing, lexical scope, good performance on huge files out of the box, extension sandboxing

I'd replace the underlying data structure used to represent buffers (https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...) with something more sophisticated, like ropes or piece tables.

Starting with some kind of namespacing solution for emacs lisp would be nice.

Add in a shortcut of : then q to quit ? ;)

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

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.)

I'd rewrite in a Clojure-like language

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

I'd ask the lem guys.

Nothing

Build it on top of Guile.

Honestly I think you could go a long way with default evil mode, and updated documentation with evil keybindings in mind.

Realize that VI was the superior editor, give up on the endeavor, print out the code I had already written for emacs, shred it, then set the shredder unceremoniously on fire.

For those that downvote me, worth it.

I'd give it a good editor.

Use python instead of lisp.

Write Vim instead. /s

I wouldn't. I just used vim

Not using lisp

Not using Lisp would be helpful

If I leapfrog over my generally cold attitude towards Lisp-like languages and my habit of Vim keys, the main problem is Emacs's sluggishness, even if it is natively compiled. Neovim fully packed with plugins, LSPs, settings and etc without lazy loading (!) is so much faster.

I’d get rid of the text editor and swap in neovim or hx code as a mode, I’d chuck emacs lisp and use Common Lisp instead, I’d definitely keep org mode and ditch old stuff like mail and news reader as core and let them be add ons written in CL . Rewrite it all in rust. That’s probably enough for today.

Don't use lisp. Normal people don't like it, it looks weird. I wonder how many projects failed because they were lisp. Normal people: Visits a project page. Sees it's a lisp. Closes page.