6 ms·

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

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.

pama 1y ago
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/fa4203300fde6820a017bf1089652fb95759d68c https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...
- tiu 1y ago
  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 https://www.youtube.com/watch?v=_qZliI1BKzI
- setopt 1y ago
  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.
  - pama 1y ago
    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.)
    - setopt 1y ago
      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.
      - pama 1y ago
        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.
  - skydhash 1y ago
    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.
  - iLemming 1y ago
    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.
koiueo 1y ago
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".
- setopt 1y ago
  > requiring you to repeatedly hit C-g at least once a day And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…
- yvdriess 1y ago
  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.
- Myrmornis 1y ago
  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.
  - koiueo 1y ago
    > 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.
    - Myrmornis 1y ago
      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.
znpy 1y ago
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.
- setopt 1y ago
  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…)
chiffaa 1y ago
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 https://github.com/lem-project/lem
- giancarlostoro 1y ago
  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.

pama 1y ago

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/fa4203300fde6820a017bf1089652fb95759d68c https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...

tiu 1y ago
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 https://www.youtube.com/watch?v=_qZliI1BKzI
setopt 1y ago
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.
- pama 1y ago
  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.)
  - setopt 1y ago
    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.
    - pama 1y ago
      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.
- skydhash 1y ago
  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.
- iLemming 1y ago
  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.

koiueo 1y ago

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".

setopt 1y ago
> requiring you to repeatedly hit C-g at least once a day And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…
yvdriess 1y ago
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.
Myrmornis 1y ago
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.
- koiueo 1y ago
  > 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.
  - Myrmornis 1y ago
    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.

znpy 1y ago

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.

setopt 1y ago
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…)

chiffaa 1y ago

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 https://github.com/lem-project/lem

giancarlostoro 1y ago
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.