IDEmacs: A Visual Studio Code clone for Emacs

I would love to see a project that rebuilds the Emacs UI but keeps the underlying core to give it a modern facelift, some things in emacs blend together and are a pain for my eyes to figure out whats what. It would be nice if the UI was modernized but the core was left as-is. I'm reminded of some of my favorite editors that are niche being Lisp related ones, where if you held down ctrl it would show you shortcuts in the UI itself and what they lead to. I also always enjoyed Racket's import arrows and other small things that are visually amazingly impressive despite being so simple.

You mean something like which-key? It existed for a long time as an external package and was added to main emacs recently. https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...

Alternatively beside which-key, hydras exist which are very nice for certain contexts (dired in the particular case for me) and provide a nice shortcut interface whenever activated. Demo at [0].

[0]: https://www.youtube.com/watch?v=_qZliI1BKzI

I'd argue the opposite. UI is ok, it can be configured to look timeless (not modern).

But the core with its single thread processing and constant hangs, requiring you to repeatedly hit C-g at least once a day, is first in line for "facelift".

> requiring you to repeatedly hit C-g at least once a day

And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…

As far as I know, which-key only helps with key sequences. If you press C-c in Org-mode it will show you keys like C-c C-e, but if you hold Ctrl down it won’t show you C-RET for example.

I would actually change as little as possible.

The current UI has it quirks, but has the great advantage that it looks the same irrespective of whether you're in an graphical environment (Xorg/Wayland/Windows/MacOS) on in a terminal (either local or remote via ssh).

I *love* that treemacs looks pretty much the same everywhere.

It's not exactly what you're looking for but you might be interested in Lem[0]. It's an emacs-style editor but written completely in Common Lisp on top of curses/SDL2. I haven't used it that much (same for Emacs itself, really), but it looks like a very solid foundation

[0]: https://github.com/lem-project/lem

Agree, those hangs are especially bad when programming with eglot or project management over a slow Tramp (remote) connection. An auto save hijacking your time for two seconds at random is flow breakingly frustrating. It's something that could perfectly well run in the background.

You can make it look modern: get rid of all menus and bars so that there is nothing on screen except for the text you're editing. (e.g. search for minimal.el) It looks indistinguishable from any other modern editor / IDE in zen mode. Menus and bars are not necessary in these sorts of applications if you use then daily -- more efficient and powerful to use the command palette and key bindings.

> nothing on screen except for the text you're editing

Just wanted to clarify, to me that's timeless. Modern would be having modern menus, pop-up configuration screen et al.. All the candy that appeals to a less experienced user, who worked with Idea, Sublime of VS code before.

If you want all keybindings, C-h b typically helps, and you can search within the single buffer it returns. Every key in Emacs is bound to something, but a plain modifier key event like Ctrl will not be sent from a terminal to any command that runs inside it, eg Emacs, only the modified key. (There exist modifications/extensions of this protocol, eg kitty, but most combinations wouldnt see these events.)

I guess I'm not really sure that menus are modern. But anyway I hate the stubbornness over the vanilla emacs UI. The nonsense in the menus and the stupid pixelated pictures of scissors or whatever.

But I've never really got the idea of why emacs should appeal to less experienced users. I think that's misguided: the entire point of Emacs is that you write some emacs lisp. If you're not interested in writing any lisp, then you definitely shouldn't bother with emacs (I used emacs intensively for 20 years and am the author of Emacs packages). And if you're less experienced and looking for Idea/Sublime experience then at this point in your life there's a good chance you aren't interested in writing lisp.

Second this. The "ui" is perhaps useful when learning to use emacs, but every emacs user I've seen after a while has all of it disabled.

I've been using emacs with the "lucid" build since forever, as it's the leanest build that still gets a graphical window working on X11 and see none of the actual "toolkit".

I guess the pgtk build is required nowdays for native wayland support.

There's a reason there's no beginner car, no beginner guitar, and no beginner drill. Those are either tools or toys. If all you want is to type some text, notepad (or the equivalent in other OS) is enough. But programmers do more with text. So they should know what tools provide those and how to use those tools. But then you'll find a lot of programmers barely go one level up from notepad with their tools.

A good shortcut is "C-h m" which shows the help for the major mode (and current active minor modes). It will also shows all the bindings that those modes define.

Sure, I know about C-h b and C-h m and find those useful. But I think what the GP post describes is more contextual: A way to not display every keybinding, but only those directly accessible by pressing the currently held modifier combo followed by one key (so holding Ctrl+Meta for more than a couple of seconds might remind you of all structural editing commands for example).

This is indeed not possible in a classical terminal emulator (don’t know if kkp for example has extensions for it). But most GUI apps can detect individual modifiers being pressed and released, even as separate events. Some editors like VSCode can also bind modifier taps to actions using this ability. In Emacs however this is AFAIK not possible even in the GUI, because of how keybindings are handled deep down.

The UI pattern described by the GP does exist in some other apps and platforms. For example, if you connect an external keyboard to an iPad, holding down the Cmd modifier for a couple of seconds will show you a popup which-key-like overview of all Cmd+key keybindings.

So we all agree we need Emacs 2.0™, rewriting both the UI and the guts? /j

It doesn’t really look the same by default.

Most new users end up disabling the toolbar, menu bar, scroll bars, etc. and only then does it look the same in the terminal. Even then, many themes and packages frivolously change font sizes or switch to non-monospace fonts in some GUI contexts, so for users that like the uniformity of the interface you need to do extra work to disable these features.

(I personally like the terminal aesthetic, and configure the GUI to look like a terminal. That basically required advising load-theme to loop over all faces and disable font properties I don’t like after each theme change…)

Does look interesting, in the meantime I've been hooked on Zed which has users building support for missing Vim features, they claim their goal isn't to 100% emulate Vim functionality, but I would not be shocked if it just winds up having most if not everything most people like about Vim fully baked in.

Agreed. I keep almost all things same between terminal and graphical UI, so I would never use it, but I can see the appeal of having the ability for handling keyboard events differently than character inputs in some cases in the GUI.

I don't agree with everything in their approach, but Lem (https://github.com/lem-project/lem) is a modern editor that has the Emacs Nature.

Yup, just the other day I was talking about it on subreddit, will repeat here verbatim:

My comment is an honest reflection of long-time Emacs usage. When I started, years ago, I just couldn't wrap my head around the fact that there were no tabs for every file anymore - the concept that was seemingly ingrained into my programmer's brain - almost in every IDE/editor I used before Emacs, I had tabs and a navigational panel on the side. I complained and demanded my tabs, asked on forums and called it "bullshit", when people calmly told me that I truly don't need them. Later I realized - they were right.

Slowly I learned that the wise choice is to remove any distractions - you don't need a minimap, side-panels, complicated modelines, and even line-numbers shown all the time. All that can be activated purposefully, on demand and then toggled off again. These "visual clues" are in fact not so much even distractions but micro-bombardments of your brain neurons - you think they are helping, while in fact they are slowly eating up your neural capacity, to the point that the brain just stops even paying attention to them and they become almost useless waste of your screen estate.

I'm not saying that this all generally true for every case and every user - some prefer certain ways, and it's great that we have a system that is able to satisfy any whim, but it's worth sometimes questioning yourself - am I enslaved by my own mental habits?

Lem looks great and I wish we all could simply move there, I personally, am not married to a concrete implementation of Emacs, I just love the idea of an editor built atop a Lisp REPL; I don't think I ever could use a computer without having it.

However, what then we'd do with nearly half-a-century history of Emacs? There are so many packages out there - it's insane to ever think we'd have to re-implement all that ginormous constellation of functionality in Common Lisp. Until we can find some quick way to translate them there, I honestly don't see any practical possibility for the migration.

Who knows, maybe agents will get so good and someone will eventually figure out a path; until then, Emacs is to remain - with all the good and bad parts.

Emacs can't do that for historic reasons. It just can't distinguish between keypress and keyup events. It receives input events from the terminal/OS. Terminals are text-oriented: They evolved to transmit characters, not hardware events.

It's not some technical impossibility - I think it would make sense to make this possible, at least in GUI Emacs. I suppose there was never a strong incentive to tackle this problem.