[HN Gopher] Ask HN: If you were rewriting Emacs from scratch, wh...
___________________________________________________________________
Ask HN: If you were rewriting Emacs from scratch, what would you do
differently?
Don't get me wrong, I'm not planning on creating an Emacs killer,
nor suggest anyone do that. But, hypothetically, what are some
fundamental pitfalls of this foundational application?
Author : volemo
Score : 32 points
Date : 2024-10-12 19:04 UTC (3 hours ago)
| sva_ wrote:
| Not using Lisp would be helpful
| volemo wrote:
| Actually, I love Emacs for its Lisp! Yes, Emacs Lisp is not the
| best Lisp out there, however, IMHO, it's miles ahead of
| VimScript. If I were really to rewrite Emacs, I'd use some
| modern Scheme.
| nabla9 wrote:
| - 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.
| shprd wrote:
| > Use Common Lisp instead of Emacs Lisp.
|
| Interesting, why not a scheme? Is it because the popularity in
| the industry? I don't know much about Emacs or lisps and
| looking to understand better
| nabla9 wrote:
| Scheme is smaller, has more static and less interactive
| philosophy. CL has most things you need straight out of the
| box. It's more like operating system than programming
| language. Exactly what Emacs wants to be.
| az09mugen wrote:
| For the Common Lisp part, someone created lem [0], but for the
| other points I can't tell. I know there is an extension manager
| being developped, but am not able to judge the robustness. Also
| that there isn't org-mode.
|
| [0] : https://github.com/lem-project/lem
| hollerith wrote:
| 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.
| tazjin wrote:
| > 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}).
| abdullahkhalids wrote:
| I have never figured out how to get a good font and rendering
| going for text in Urdu/arabic script.
| hollerith wrote:
| Huh. I use pgtk Emacs, too, and am surprised to find someone
| who doesn't find my statement obvious.
| tazjin wrote:
| Well, if there's no further info then I'm going to
| speculate you've misconfigured something ;)
| actionfromafar wrote:
| Ok then, "make it harder to hold it wrong". :)
| hollerith wrote:
| Most of the text on the web for example is in a proportional-
| pitch typeface.
|
| Does your Emacs usually use a proportional-pitch typeface? If
| so and you're on Linux, I'll install the font you are using.
|
| I've tried using proportional typefaces in Emacs (on Mac),
| but there was something off, so I went back to monospaced. I
| could try again now that I have a Linux machine.
|
| The text in my Emacs looks almost exactly like the text in my
| Gnome Terminal. (A slight difference in size is the only
| thing I notice. To be painfully precise, (window-system)
| evals to 'pgtk on my Emacs.)
|
| The text in Gnome Terminal is not terrible, for sure, but
| text on the web is a little nicer.
| tazjin wrote:
| I used to use proportional pitch fonts for telega.el and
| certain document buffers, but I stopped because I find that
| with Jetbrains Mono (for me personally) there isn't any
| benefit even for longer text. I'd rather have everything be
| uniform.
|
| Emacs is perfectly capable of rendering other fonts, too,
| though.
| susam wrote:
| 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/>.
| smokel wrote:
| Make CapsLock an additional Ctrl. On many old keyboards that is
| where the Ctrl key was positioned [1].
|
| [1] https://en.m.wikipedia.org/wiki/Caps_Lock#Placement
| susam wrote:
| I know many people like to remap Caps Lock to function as
| Ctrl. However that setup does not quite work for me. There is
| only one Caps Lock key on the left side of the keyboard. I
| need Ctrl on both sides of the keyboard, so that I can use
| the left Ctrl key while typing Ctrl+P but the right one while
| typing Ctrl+A.
|
| There are other options as well, like remapping the Enter key
| to act as Ctrl when chorded or using sticky modifiers. I
| think using an ergonomic keyboard with two large Ctrl keys on
| both sides of the keyboard is probably the best solution.
| I've discussed some of these alternatives in more detail
| <https://susam.github.io/devil/#why>.
|
| By the way, there are some vendors that still make Unix
| layout keyboards with the Ctrl key positioned where Caps Lock
| key usually is: <https://deskthority.net/wiki/Category:Keyboa
| rds_with_Unix_la...>.
| tom_ wrote:
| I just leave Ctrl where it is and press it with the knuckle
| of my little finger. I do it just like the guy in the pic
| on this page, pressing the control key with his little
| finger:
| http://xahlee.info/kbd/how_to_press_control_key.html -
| because that pic is of my hand. (Xah might not recommend
| doing this all the time, but I've been doing this for
| nearly 20 years now and I've had no problems.)
| imiric wrote:
| Instead of making it an additional Ctrl key, you can also
| make it a new separate modifier key with XKB[1]. I've found
| this very useful over the years for WM-related key bindings,
| leaving the other modifiers for applications.
|
| Tangentially, I really loathe how Wayland has no alternative
| to this. I'm expected to configure keyboard layouts in every
| DE or WM I use, which is a much worse UX.
|
| [1]: https://vincent.bernat.ch/en/extending-xkb#attaching-
| symbols...
| macintux wrote:
| I was very disappointed that Apple gave up that fight.
|
| They also at some point joined the PC world in moving the
| nubs on their keyboard from "d" and "k", where you were more
| likely to notice if your fingers are not in their proper
| place on the home row. Now if your right hand is offset
| slightly to the right, you won't feel anything, which is less
| immediately noticeable than if the nub were under the wrong
| finger.
| fsckboy wrote:
| emacs is not its keybindings. you can bind your emacs keyboard
| to do what you are asking for; as you said, you wrote a mode
| for emacs that works the way you want, and it wasn't necessary
| to rewrite Emacs.
| susam wrote:
| > emacs is not its keybindings ... and it wasn't necessary to
| rewrite Emacs
|
| That's indeed true! But the premise of this question explores
| the scenario: _What if we did rewrite Emacs from scratch?_
| bitwize wrote:
| Build it on top of Guile.
| wwarner wrote:
| 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.
| eointierney wrote:
| 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.
| denotational wrote:
| Ok, you had me for the first three sentences.
| neilv wrote:
| Implemented mostly in Guile, with just some native
| primitives/kernel bits in Rust, makes a lot of sense, for an
| programmer's application platform in the spirit of Emacs.
| fsckboy wrote:
| > _beard length is gendered_
|
| you insensitive clod
|
| https://www.gocomics.com/calvinandhobbes/1986/02/14
| sshine wrote:
| > _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._
|
| Since I agreed with all of these, I'll add some more non-
| ironic, idealistic wishes:
|
| Plugins must be written in sandboxed WebAssembly so you can
| know what a plugin is capable of without reading the source
| code. The runtime must be portable so it can run in
| wasm32-wasi.
| otabdeveloper4 wrote:
| 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.)
| JadeNB wrote:
| > Emacs is fine, but buggy as hell.
|
| Is this so obvious as to go without examples? I'm no Emacs
| power user, nor even really an Emacs user, but it certainly
| conflicts with my understanding of core Emacs.
| peter-m80 wrote:
| Not using lisp
| m463 wrote:
| why the downvotes? This is a reasonable point of view.
|
| I sometimes think using lisp for a language is a little like
| trying to implement comments within json data.
| sno129 wrote:
| Write Vim instead. /s
| dmitrygr wrote:
| > 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.
| maxk42 wrote:
| Prefer Tauri to Electron. It is 2024, after all.
| Crosseye_Jack wrote:
| LGTM: Ship it!
| aardvark179 wrote:
| Thanks, I hate it.
| stormking wrote:
| A modern display engine.
| federicotdn wrote:
| 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.
| bbarnett wrote:
| All sensible email clients have a 'thread view' for just this
| purpose, which effectively makes it a 'single conversation
| thread'.
| federicotdn wrote:
| Yes, the Gmail web client does this. However my (personal)
| problem comes more from reading the emacs-devel archives,
| where the thread view takes the shape of something more like
| a tree (maybe I'm not configuring something correctly). I was
| subscribed to emacs-devel at some point (which made reading
| easier) but it started filling up my account storage so I un-
| subscribed.
| varjag wrote:
| Allow for user controllable window layout within the frame,
| objectively the editor's only significant drawback.
| floren wrote:
| god yes please. "Will I get a new window? If so, where will it
| be?"
|
| If I could have Emacs with Acme-style window management, that'd
| be perfect
| dilap wrote:
| 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).
| the_clarence wrote:
| I would probably just implement vscode but for the terminal.
| Emacs shortcuts already work by default in vscode for the most
| part.
| sshine wrote:
| While Emacs is recognisable for its shortcuts, it is hardly a
| defining feature. Example: Doom Emacs adds Vim shortcuts, and
| it is still distinctly Emacs.
|
| I think of VSCode as "Emacs, but JavaScript instead of Elisp."
| That's one thing I would not choose, in spite of the good
| things VSCode brings to the table.
| azram wrote:
| Nothing
| I_complete_me wrote:
| I too use vim.
| lysace wrote:
| Use python instead of lisp.
| m463 wrote:
| I agree.
|
| Maybe it's just personal preference, since I think it's easier
| for me to think in python over lisp (which I've known for
| longer, but I still fumble through)
|
| I do think python would make emacs more accessible to a wider
| audience.
| intellectronica wrote:
| Scheme instead of ELISP. Concurrency (Async IO would do).
| mrob wrote:
| 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.)
| yoavm wrote:
| Vim has the same problem:
| https://github.com/neovim/neovim/issues/989
| arghnoname wrote:
| I'll try to use the more common Windows/MacOS terms for it, but
| in emacs I often have the same file opened in two different
| panes within one window or two separate windows. I do this when
| I want to be looking at one part of a file while editing
| another.
|
| Markers are used to mark a different point in the file and one
| can pop their location to a previous mark.
| mrob wrote:
| Putting cursors within the document does not preclude
| supporting different cursors for different windows.
| tom_ wrote:
| This still annoys me slightly after nearly 20 years of using
| Emacs.
|
| In response to keypresses, it doesn't bother me too much, as
| I'm used to the Windows-style behaviour of PgUp/PgDn/etc.
| moving the caret, much as the Mac behaviour of not doing that
| is sometimes useful. But for mouse wheel scrolling, which I do
| a lot - precisely because on Windows this typically does _not_
| move the caret! - having point follow along has never felt
| right.
| faizshah wrote:
| 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.
| musicale wrote:
| 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.
| lysace wrote:
| I'm confused. On the modern devices I've recently used emacs on
| (including very low-powered raspberry pi devices), all of your
| three criteria are already true.
|
| What kind of HW are you running emacs on where this isn't the
| case?
| arghnoname wrote:
| Emacs pauses are almost always due to some operation blocking
| in the main thread. It's pretty annoying and is mostly a
| consequence to a lot of things effectively being single-
| threaded. Stock emacs doesn't do this very often, but third
| party packages that might do expensive tasks often do
| lysace wrote:
| Ah. A case of "don't do that, then".
| musicale wrote:
| This is from 2015, but emacs still has higher typing latency
| than vim in 2024.
|
| https://pavelfatin.com/typing-with-pleasure/
|
| (On a related note, I would like iTerm2 but I find it
| painfully sluggish compared to Terminal.)
|
| If you have better numbers and comparisons for emacs
| keypress-to-pixel latency, etc. I'd be interested.
|
| Note classic vi started up much faster than vim.
|
| Device makes no difference: Raspberry Pi 5, MacBook Pro M1,
| ThinkPad P1, etc. - emacs is clunky on all of them. I like
| emacs and it is my primary editor. But it isn't fast.
| mikewarot wrote:
| 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
| khazhoux wrote:
| Emacs is the shittiest tool I've been using since 1992 and will
| use till I die.
| buescher wrote:
| 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.
| aardvark179 wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-12 23:00 UTC)