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.
Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
81–90 of 340 posts
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#82I 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.
You could also start at the bytecode level so that the specific language itself is less relevant.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#83I would probably just implement vscode but for the terminal. Emacs shortcuts already work by default in vscode for the most part.
None of the main selling points of emacs have anything to do with its shortcuts or using it in the terminal. Plenty of emacs users (including me) rarely or never use it in the terminal. It’s a GUI editor just like vscode is.
I think this misconception comes from the fact that (1) people often compare emacs and vim, and (2) vim is usually used in the terminal. But emacs and vim are really categorically different things so I think the “emacs vs. vim” meme kinda doesn’t make sense.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#841. 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!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.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#85Emacs 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.)
Emacs is fine, but buggy as hell.
Ship is fine, but leaks as hell.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#86Don'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.
Parentheses scare away anyone who shouts "bro!" and fist-bumps each other, before they can insist "the first thing Emacs needs is a package manager, to hide code as much as possible from casual users" (missing half the point of Emacs).
Emacs has a package manager...
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#87I would probably just implement vscode but for the terminal. Emacs shortcuts already work by default in vscode for the most part.
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.
Can I hit one key combination to edit the JavaScript corresponding to any vscode command, debug it and possibly modify it however I want? If not, it’s not really comparable to emacs IMO.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#88Emacs 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.)
Emacs is fine, but buggy as hell. That kind of took 180 turn on that one. Ship is fine, but leaks as hell.
As long as I can keep this ship, I will keep bailing.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#89I'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.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#90I'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…
It (kinda) has multiple cursors per document if you split the frame and display the buffer twice. For longer source files I find myself splitting horizontally, editing in the left pane, and using the right pane for secondary movement and reference.
I have a buffer manager that can switch the displayed buffer quickly, when I switch to a different buffer and back again, it retains it's "secondary" cursor position that is separate from the other view.