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.
Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
11–20 of 340 posts
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#12Instead 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/ >.
Make CapsLock an additional Ctrl. On many old keyboards that is where the Ctrl key was positioned [1].
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#13The 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.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#14Emacs 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.)
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#15Not using lisp
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#16Write Vim instead. /s
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#17The 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-che…
Ok, you had me for the first three sentences.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#18[deleted]
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#19Support 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 key…
> If text in Emacs looked as pretty as text on the web does
Do you have an example of this? I can't tell any difference for the fonts that I use (with emacs-pgtk). I believe Emacs uses Harfbuzz (same as Chrom{e|ium}).
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#20> 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.