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.
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.)
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.
Vim has the same problem: https://github.com/neovim/neovim/issues/989
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.
> 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.
Iam pretty sure you can customzize that if you want.
> scroll-preserve-screen-position is a variable defined in ‘C source code’.
> Its value is ‘keep’ > Original value was nil
> Controls if scroll commands move point to keep its screen position unchanged.
> A value of nil means point does not keep its screen position except > at the scroll margin or window boundary respectively.
> A value of t means point keeps its screen position if the scroll > command moved it vertically out of the window, e.g. when scrolling > by full screens. If point is within ‘next-screen-context-lines’ lines > from the edges of the window, point will typically not keep its screen > position when doing commands like ‘scroll-up-command’/‘scroll-down-command’ > and the like.
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.
Putting cursors within the document does not preclude supporting different cursors for different windows.
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?
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!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 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.
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?
This is from 2015, but emacs still has higher typing latency than vim in 2024.
https://pavelfatin.com/typing-with-pleasure/
If you have better numbers and comparisons for emacs keypress-to-pixel latency, etc. I'd be interested.
Note classic vi started up faster than vim.
Device makes little to no difference: Raspberry Pi 5, MacBook Pro M1, ThinkPad P1, etc. - emacs is clunky on all of them. I like emacs and it's my daily driver. But it isn't fast.
see also:
"Computer latency: 1997-2017" https://danluu.com/input-lag/
"Measuring keyboard-to-photon latency with a light sensor" https://thume.ca/2020/05/20/making-a-latency-tester/
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
Receiving output from a process, as is done for example by shell mode and (I guess, but have not verified) compilation mode, is slow in Emacs because all output is run through comint-carriage-motion and ansi-color-filter-region (which does nothing but throw color information away IIRC) which are written in Elisp.
If you don't run the output through those 2 functions, then non-printing characters remain in the output that severely undermine legibility.
C programmers tend to develop the ability to glean information from the voluminous output of build processes as it goes whizzing by on a terminal, so they find compilation mode frustratingly slow. Or at least that is my guess as to what happens.
For instant startup I recommend daemon mode and emacsclient. Start emacs via emacs --daemon, open windows (in the terminal or otherwise) via `emacsclient` / `emacsclient -nc` (I use aliases for these).
I wrap my slow .emacs loads inside #'run-with-idle-timer so they run when I'm not looking, and not likely to notice.
Yep, warm start is the only way to go unfortunately. But I want a fast start from cold boot like classic vi.
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.
> 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}).
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 nicer in my experience.
Huh. I use pgtk Emacs, too, and am surprised to find someone who doesn't find my statement obvious.
I have never figured out how to get a good font and rendering going for text in Urdu/arabic script.
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.
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/>.
Make CapsLock an additional Ctrl. On many old keyboards that is where the Ctrl key was positioned [1].
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...
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:Keyboards_with_Unix_la...>.
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.
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.
> 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?
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.
- 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.
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.
> 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
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.
Rendering performance is still my main gripe and the one most mentioned by vim users I unsuccessfully tried to convert through evil mode.
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
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).
Emacs is the shittiest tool I’ve been using since 1992 and will use till I die.
It's the finest manure to fertilize thought we can turn over with only a fork
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.
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.
Yes
relevant: https://github.com/remacs/remacs#rust-heart-emacs although as of this message it says they've given up in favor of https://github.com/emacs-ng/emacs-ng#contributing which does mention Rust but seems to be ... a lot different from Emacs so I guess they're really going all-in on the "NG" part
for the non-tongue-in-cheek, also relevant: https://www.emacswiki.org/emacs/GuileEmacs#h5o-2
Ok, you had me for the first three sentences.
Implemented mostly in Guile, with just some native primitives/kernel bits in Rust, makes a lot of sense, for a programmer's application platform in the spirit of Emacs.
> 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.
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.
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.
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.
I recently learned FSF does have a GL instance but it seems to be locked down to just "approved" emails and also only used for its CI capabilities: https://emba.gnu.org/emacs/emacs/-/pipelines
All sensible email clients have a 'thread view' for just this purpose, which effectively makes it a 'single conversation thread'.
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.
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.
emacs-ng cites Deno, which speaks to your "more mainstream" as well as some of the sandboxing concerns offered by others https://github.com/emacs-ng/emacs-ng#denojavascript
You could also start at the bytecode level so that the specific language itself is less relevant.
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.
Allow for user controllable window layout within the frame, objectively the editor's only significant drawback.
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
this is emacs territory so we have infinite customization via the `display-buffer` primitive.
see https://www.masteringemacs.org/article/demystifying-emacs-wi... for more information.
A modern display engine.
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.
First of all, I would make sure that it would not be swapping constantly when running on eight megabytes!
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.)
Emacs is fine, but buggy as hell.
Ship is fine, but leaks as hell.
As long as I can keep this ship, I will keep bailing.
> 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.
Build it with emacs
Scheme instead of ELISP. Concurrency (Async IO would do).
I 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.
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.
Nothing
I too use vim.
Use python instead of lisp.
There's the Leo editor, if Python's what you want: https://leo-editor.github.io/leo-editor/
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.
Build it on top of Guile.
Write Vim instead. /s
> 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.
Prefer Tauri to Electron. It is 2024, after all.
LGTM: Ship it!
Thanks, I hate it.
Not using lisp
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.
Not using Lisp would be helpful
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.
Fennel is a better Lisp than elisp. Neovim is extensible, and to a large degree written in, Lua, which the target language of Fennel.
Most developers do not like writing Lisp. That's just a fact, slamming the downvote button won't change it. I am not among those developers, I like writing Lisp, but most, flatly put, do not.
So by choosing Scheme you are competing with a remarkable number of little-used editors which can be extended in Scheme or Common Lisp, as well as Emacs, far and away the top dog in the extensible-in-Lisp-editor niche. Neovim has achieved the best of both worlds, because it can be extended in a rather nice Lisp, and also in Lua, which, while some find the quirks of the language annoying, is at least Algolic in structure, matching the mode of thinking and writing used by the vast majority of devs.
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.
And how would that make emacs better?
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...