I love these packages (like this, Spacemacs, Doom, etc.), even though I've used Emacs for over 30 years. I don't use them directly, but they give me ideas and alert me to packages I haven't heard of (eat?). And that gives me an excuse to go on another round of config-tweaking, which any Emacs user loves.
As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config.
Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?
I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity.
More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe.
My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.
Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.
I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..
VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity.
I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result.
My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults.
For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
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.
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".
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.
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.
> 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.
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.
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.
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
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].
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.
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.
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.)
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.
onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim .
neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing).
Thanks for the clarification.
The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
Love to see this. I lost steam working my way through SICP a couple of years ago because I spent so much time trying to figure out Emacs instead of writing Scheme
This won't take me away from Doom Emacs---I prefer the keyboard centric approach of Doom---but I'm really happy to see this. I feel that Emacs has some really innovative UI plugins (things like Vertico) but the out-of-the-box experience is pretty bad. If this makes Emacs more accessible to a different group of people I think it's great.
i still use emacs everyday, with the native UI. but i love the idea of this project. Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons.
This would have been great when I was learning Lisp in school! I tried emacs but due to joint issues the keybinds were painful to use, so I gave up and did the course in vim+SBCL's REPL instead.
It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense.
I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.
How does this configuration behave in a non-graphical terminal, e.g. as used with SSH? Can we have something that's at least on par with the UX from the old Borland text-based Turbo Vision IDE's (Turbo Pascal/Turbo C++), with a few modern convenience features?
This is great to see, and I'm sure it will nudge some people to give Emacs a try who wouldn't have otherwise.
I've been using Emacs with a custom configuration for many years now, but when I needed a good IDE for working with modern frontend stacks about a year ago, I decided to give VSCodium a try, since the TS/LSP integration wasn't that great in Emacs. And funnily enough, I did the reverse of what this project does: I tried to make VSCodium look and behave more like my Emacs setup.
It turns out that this is incredibly difficult. Decluttering the UI was easy enough; getting my Vim/evil-mode key bindings to work was relatively straightforward, though not perfect; but it was practically impossible to make VSCode work with the concept of buffers, instead of tabs and tab groups.
There are some extensions that emulate this to an extent, but it requires at least one change[1] to work properly that's been ignored for almost 2 years now.
So, that, general jank and unresponsiveness, and the idea of my editor being a web browser with all the security concerns of installing random JS extensions, put me off it for good. I went back to my "inferior" Emacs setup, spent some more time on configuring it for TS, and I think it's not so bad right now. Though I switched projects in the meantime, so it probably needs to be brought up to date again.
Moral of the story: Emacs is life. I'm sorry I ever doubted it. <3
What I miss from vscode is the remote functionality, can you do it with emacs? For neovim there is distant.nvim, but idk if it is mature enough and configuration seems a bit annoying...
In my experience TRAMP is not a sensible answer to this question. It doesn’t provide the same remote editing functionality that vscode does (albeit through a heavy handed approach) due to the lag and file browsing/search interface. It’s a similar story with remote debugging. emacs dape is pretty good but feels high friction compared to the dap integration in vscode. I would love to switch away from vscode, but these two features are still killer.
Emacs already does that with TRAMP via SSH -- You just open a file like /ssh:user@server:/etc/hosts the main downside is if your connection is laggy Emacs will lock up momentarily. There is an ongoing effort to improve the multithreaded-ness and async-ness of Emacs to make it nicer
I use TRAMP to edit code loaded on robots occasionally. One advantage compared to VSCode is that it doesn't require the installation of anything onto the computer you're connecting to, since it uses the usual linux tools to work. But it can freeze up once in a while.
Well, I guess? Using TRAMP with large projects is not a pleasant experience. It works great for one-off files and remote bookmarks etc, but for working with large projects you're better off mosh/ssh-ing into the server and using Emacs there. With things like term-keys [1] you can use all the keys there as well. Basically only missing out on images and variable fonts, both of which are none issues for me at least when programming.
C-x, C-c, C-w, C-s, C-k, C-g, C-] - goodness me, somebody absolutely does not give a shit what anybody thinks. I would never use this, but, somehow, I still love it.
In fairness, Emacs has long had cua-mode for rebinding C-c, C-v, C-x, and C-z to copy, paste, cut, and undo, so at least those changes are not too radical.
Agree with you. Coming from sublime and always wanting to give emacs a fair try, I found ergoemacs [0] that wanted to expand the cua mode for beginners, but that was not enough for me. I wanted more, and now with IDEmacs it is almost like what I want. With emacs you can do pretty much anything, why not a full cua mode ?
I don't see a point to this beyond hack value. Turning Emacs into a shitty version of an inferior editor is kind of a waste. If you really want Visual Studio Code, just use Visual Studio Code.
For me, VSCode implements everything that I've always expected from Emacs/Vim.
I've spent years to configure emacs/vim to be a good programming editor. Years, multiple configurations, vanilla configs, space/doom emacs configs, multiple predefined configs for vim/neovim. Something always was broken, something was missing, something was non-optimal just below the tolerance line. Missing features, discontinued packages, initialization errors, bad versions, "known issues", LSPs not starting, packages replaced by some newer shinier package with different usage, cryptic setups that are wrapped in "convenience layers" that obscure details, making it completely incomprehensible.
Then VSCode came and it had everything. Remote development is trivial through ssh. Completion simply works without any setups. Massive number of languages supported. It's a mess inside, but the UX is more stable and more consistent than anything I've ever seen in emacs/vim. Sometimes something breaks, but I can restart the window backend without closing the app easily.
This is really telling. Despite dedicating years to configure an "infinitely configurable" system, I wasn't able to achieve anything stable. I've given up and i just use VSCode daily. This way, I have more than I ever had with emacs/vim.
The only thing I have from vim that's left is the keyboard layout. For this, I'm thankful to Vim, but the editor itself for me is just for editing config files. I don't even have Emacs installed anymore.
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.
I would really like to see this kind of work be done upstream. Emacs still looks the same as it did decades ago despite other editors advancing and becoming more user friendly.
Switching the default experience away from what people have grown used to over decades seems incredibly rude (despite what commercial software has normalized).
The magic of emacs is infinite customizability. And it's quite easy for users to find and start with emacs "distributions" or "starter packs". So that's probably the best route forward.
Potential improvements:
1 Base emacs continues to make it easier to try out a bunch of configurations and switch between them, obviating solutions like chemacs
2 There's a web repository of a a variety of starter packs with screenshots and reviews and installation instructions, to help beginners find everything in one place.
The curse as a power user is that you want to know how it works. I let that feeling go with emacs. I've been happily using it since. My first gateway and killer use case was magit. Life with git will never be the same.
> Emacs still looks the same as it did decades ago
That’s a good thing. I don’t want to change my habits every time a designer of whatever product I use decides that he deserves a raise and breaks my workflow in some subtle way.
Please, no. Emacs could use some interface/toolkit update, I don't deny that. And I like IDE features. I use tree-sitter, LSPs, copilot.el, copilot-chat.el, and others all day, every day.
But don't force me to turn off treemacs, and minimap like I have to do in VSCode all the time just because some useless, space-wasting eye-candy is trendy.
I didn't downvote you, but you have a misconception.
There's no such thing as an Emacs "look". Its appearance, UI and UX, are wildly different depending on how the user wants it to look and behave. Considering that it is a very configurable system that happens to expose building blocks for a text editor, every Emacs installation is thus different from another.
We could say that the Emacs GUI toolkit and perhaps its internals are dated by modern standards, but even those would be personal preferences. Being single-threaded is arguably holding it back in some aspects, though that isn't a major limitation for most use cases.
It can hardly be called resistance to improvement, when everyone do improve it - just in their own ways. The default isn't some fashion statement, some aesthete that's objectively good (though I am sure some people do subjectively like it). But it's meant to be sort of a least presumptuous blank state that everyone can radically overhaul. So arguably it's an encouragement for improvement just like everything else in Emacs, which focuses on making the tools for improvement easier.
It's just that "improvement" as a matter of public consensus that everyone can agree on to elect the next blank slate has been to impossible to settle on. But the counterculture here broadly might be extreme reluctance to inconvenience even a minority of existing users, in pursuit of market share/growth.
Nonsense. Many emacs users spend their whole lives inside of it so they're quite sensitive to what is actually an improvement and what is not. The arrival of the various modern completion packages -- vertico, orderless, consult, etc. have been welcomed ... but note that these are all add-on packages. Likewise, all of the "improvements" provided by the OP are a matter of loading and configuring packages.
People who aren't regular emacs users tend not to understand it and are not reliable reporters about the editor or its community.
Yep. Look at IntelliJ. It just copied VsCode when it already had a great UI where things were easy to find and consistent. Now it’s got meaningless icons and hides important stuff by default, making it modern but far worse than before. Thank goodness emacs is not trying to chase the latest and stupidest.
There is no better UI for text editing that I have ever come across. I'm not sure why so many people are resistant to the idea that emacs has the correct answer to most UI issues. More programs would stand to take lessons from emacs. Emacs is, in its own right, a very successful piece of software. When eclipse was a thing everyone was saying how great it was vs emacs. But eclipse is gone (I think?) and emacs is still GOATed.
There's a particular kind of hubris from non emacs users (especially those who swear by new ides), that us losers are somehow deprived. We are not and don't need your advice. Nothing to do with counterculture. I tried many editors before I became obsessed with emacs.
>But eclipse is gone (I think?) and emacs is still GOATed.
The 2024 stack overflow developer survey [0] puts Eclipse at over double Emac's market share. If Eclipse is gone, then Emacs is double gone. Emacs struggles to attract and retain new users. This advice is not calling existing Emacs users deprived. It's rooted from the bad defaults giving new users a bad impression of Emac's viability because the default is so bad. If emacs built out proper telemtry they could actually track how the defaults they provide affect the new user experience in order for them to optimize it and figure out what users are looking for.
It’s not counterculture. It’s understanding of what’s important. Functionality, discoverability and extendability over opinionated UI/UX that nobody asked for.
I love these packages (like this, Spacemacs, Doom, etc.), even though I've used Emacs for over 30 years. I don't use them directly, but they give me ideas and alert me to packages I haven't heard of (eat?). And that gives me an excuse to go on another round of config-tweaking, which any Emacs user loves.
As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config.
Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?
I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity.
More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe.
My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.
Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.
I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..
VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity.
I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result.
My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults.
For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
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.
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".
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.
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.
> 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.
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.
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.
> requiring you to repeatedly hit C-g at least once a day
And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…
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
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
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.
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.
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 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.
I was always bummed OniVim v2 didn't take off.
It was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim .
neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
From a quick glance, I can't understand the target audience.
Vim users would be annoyed by bizarre input lag of an electron application and perhaps by EULA. VS code users don't really care about Vim...
>of an electron application
It isn't an Electron application*, that's why GP said native. The EULA part though was probably a block to adoption.
*It uses Revery, a, made by OniVim's devs, cross-platform GUI framework (similar to Flutter but build on Reason/OCaml).
Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing). Thanks for the clarification.
The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
Love to see this. I lost steam working my way through SICP a couple of years ago because I spent so much time trying to figure out Emacs instead of writing Scheme
This won't take me away from Doom Emacs---I prefer the keyboard centric approach of Doom---but I'm really happy to see this. I feel that Emacs has some really innovative UI plugins (things like Vertico) but the out-of-the-box experience is pretty bad. If this makes Emacs more accessible to a different group of people I think it's great.
i still use emacs everyday, with the native UI. but i love the idea of this project. Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons.
This would have been great when I was learning Lisp in school! I tried emacs but due to joint issues the keybinds were painful to use, so I gave up and did the course in vim+SBCL's REPL instead.
It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense.
I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.
I use kmonad to make Space act as Control when held, and it's absolutely life-changing - not just in Emacs, but in all applications.
This is my configuration -
https://codeberg.org/contrapunctus/dotfiles/src/branch/produ...
And here's my blog post about it -
https://contrapunctus.codeberg.page/blog/keyboard-machinatio...
wait foot pedals ?
Which joint issues? Have you tried evil mode?
> Which joint issues?
Pretty sure it's rheumatoid arthritis.
> Have you tried evil mode?
This was like fifteen years ago and I just went back to my working Vim setup I was already using for all my other classes.
How does this configuration behave in a non-graphical terminal, e.g. as used with SSH? Can we have something that's at least on par with the UX from the old Borland text-based Turbo Vision IDE's (Turbo Pascal/Turbo C++), with a few modern convenience features?
This is great to see, and I'm sure it will nudge some people to give Emacs a try who wouldn't have otherwise.
I've been using Emacs with a custom configuration for many years now, but when I needed a good IDE for working with modern frontend stacks about a year ago, I decided to give VSCodium a try, since the TS/LSP integration wasn't that great in Emacs. And funnily enough, I did the reverse of what this project does: I tried to make VSCodium look and behave more like my Emacs setup.
It turns out that this is incredibly difficult. Decluttering the UI was easy enough; getting my Vim/evil-mode key bindings to work was relatively straightforward, though not perfect; but it was practically impossible to make VSCode work with the concept of buffers, instead of tabs and tab groups.
There are some extensions that emulate this to an extent, but it requires at least one change[1] to work properly that's been ignored for almost 2 years now.
So, that, general jank and unresponsiveness, and the idea of my editor being a web browser with all the security concerns of installing random JS extensions, put me off it for good. I went back to my "inferior" Emacs setup, spent some more time on configuring it for TS, and I think it's not so bad right now. Though I switched projects in the meantime, so it probably needs to be brought up to date again.
Moral of the story: Emacs is life. I'm sorry I ever doubted it. <3
[1]: https://github.com/microsoft/vscode/issues/204942
What I miss from vscode is the remote functionality, can you do it with emacs? For neovim there is distant.nvim, but idk if it is mature enough and configuration seems a bit annoying...
In my experience TRAMP is not a sensible answer to this question. It doesn’t provide the same remote editing functionality that vscode does (albeit through a heavy handed approach) due to the lag and file browsing/search interface. It’s a similar story with remote debugging. emacs dape is pretty good but feels high friction compared to the dap integration in vscode. I would love to switch away from vscode, but these two features are still killer.
Emacs already does that with TRAMP via SSH -- You just open a file like /ssh:user@server:/etc/hosts the main downside is if your connection is laggy Emacs will lock up momentarily. There is an ongoing effort to improve the multithreaded-ness and async-ness of Emacs to make it nicer
I use TRAMP to edit code loaded on robots occasionally. One advantage compared to VSCode is that it doesn't require the installation of anything onto the computer you're connecting to, since it uses the usual linux tools to work. But it can freeze up once in a while.
What kind of remote functionality? Lately, somebody mentioned https://code.visualstudio.com/docs/remote/tunnels
There is TRAMP.
https://www.gnu.org/software/tramp/
I am not sure if it will fit your needs or not.
I believe the analogous thing in emacs is called TRAMP. I have no idea if it's good, as I never edit files remotely, but it exists.
Not at the same level. TRAMP is way behind feature-wise.
You mean like the way VSCode does by installing a whole mini version of itself on the remote computer?
Well, I guess? Using TRAMP with large projects is not a pleasant experience. It works great for one-off files and remote bookmarks etc, but for working with large projects you're better off mosh/ssh-ing into the server and using Emacs there. With things like term-keys [1] you can use all the keys there as well. Basically only missing out on images and variable fonts, both of which are none issues for me at least when programming.
1: https://github.com/CyberShadow/term-keys
.... and then he lisped in her ear: "Wanna come, see my Emacs at home? It's huge."
If you don’t use it that often, you might wanna try the Emacs plugin for VS Code instead.
What on earth are you talking about?
Do you have any recommendations?
Yes the best one is https://marketplace.visualstudio.com/items?itemName=tuttieee...
C-x, C-c, C-w, C-s, C-k, C-g, C-] - goodness me, somebody absolutely does not give a shit what anybody thinks. I would never use this, but, somehow, I still love it.
I dare the author to rebind M-x as well.
In fairness, Emacs has long had cua-mode for rebinding C-c, C-v, C-x, and C-z to copy, paste, cut, and undo, so at least those changes are not too radical.
Agree with you. Coming from sublime and always wanting to give emacs a fair try, I found ergoemacs [0] that wanted to expand the cua mode for beginners, but that was not enough for me. I wanted more, and now with IDEmacs it is almost like what I want. With emacs you can do pretty much anything, why not a full cua mode ?
[0] : https://ergoemacs.github.io/
I don't see a point to this beyond hack value. Turning Emacs into a shitty version of an inferior editor is kind of a waste. If you really want Visual Studio Code, just use Visual Studio Code.
That screenshot is super pretty. Very impressive!
Thank you!
I like to express my loyalty to the emperor of man and call this heresy
For me, VSCode implements everything that I've always expected from Emacs/Vim.
I've spent years to configure emacs/vim to be a good programming editor. Years, multiple configurations, vanilla configs, space/doom emacs configs, multiple predefined configs for vim/neovim. Something always was broken, something was missing, something was non-optimal just below the tolerance line. Missing features, discontinued packages, initialization errors, bad versions, "known issues", LSPs not starting, packages replaced by some newer shinier package with different usage, cryptic setups that are wrapped in "convenience layers" that obscure details, making it completely incomprehensible.
Then VSCode came and it had everything. Remote development is trivial through ssh. Completion simply works without any setups. Massive number of languages supported. It's a mess inside, but the UX is more stable and more consistent than anything I've ever seen in emacs/vim. Sometimes something breaks, but I can restart the window backend without closing the app easily.
This is really telling. Despite dedicating years to configure an "infinitely configurable" system, I wasn't able to achieve anything stable. I've given up and i just use VSCode daily. This way, I have more than I ever had with emacs/vim.
The only thing I have from vim that's left is the keyboard layout. For this, I'm thankful to Vim, but the editor itself for me is just for editing config files. I don't even have Emacs installed anymore.
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.
I would really like to see this kind of work be done upstream. Emacs still looks the same as it did decades ago despite other editors advancing and becoming more user friendly.
Switching the default experience away from what people have grown used to over decades seems incredibly rude (despite what commercial software has normalized).
The magic of emacs is infinite customizability. And it's quite easy for users to find and start with emacs "distributions" or "starter packs". So that's probably the best route forward.
Potential improvements:
1 Base emacs continues to make it easier to try out a bunch of configurations and switch between them, obviating solutions like chemacs
2 There's a web repository of a a variety of starter packs with screenshots and reviews and installation instructions, to help beginners find everything in one place.
3 ...
Could be done with a flag tbh. One version to opt in. Next version it’s opt out.
Emacs is probably the most user-friendly editor. Its just not very beginner-friendly.
The problem is that you need to spend 20 years to get out of the "beginner" zone.
The curse as a power user is that you want to know how it works. I let that feeling go with emacs. I've been happily using it since. My first gateway and killer use case was magit. Life with git will never be the same.
> Emacs still looks the same as it did decades ago
That’s a good thing. I don’t want to change my habits every time a designer of whatever product I use decides that he deserves a raise and breaks my workflow in some subtle way.
Please, no. Emacs could use some interface/toolkit update, I don't deny that. And I like IDE features. I use tree-sitter, LSPs, copilot.el, copilot-chat.el, and others all day, every day.
But don't force me to turn off treemacs, and minimap like I have to do in VSCode all the time just because some useless, space-wasting eye-candy is trendy.
I'm afraid that many people consider "looking the same as decades ago" a feature...
I didn't downvote you, but you have a misconception.
There's no such thing as an Emacs "look". Its appearance, UI and UX, are wildly different depending on how the user wants it to look and behave. Considering that it is a very configurable system that happens to expose building blocks for a text editor, every Emacs installation is thus different from another.
We could say that the Emacs GUI toolkit and perhaps its internals are dated by modern standards, but even those would be personal preferences. Being single-threaded is arguably holding it back in some aspects, though that isn't a major limitation for most use cases.
A huge portion of the emacs community seems resistant to any UI improvement. I think it's a counterculture thing.
It can hardly be called resistance to improvement, when everyone do improve it - just in their own ways. The default isn't some fashion statement, some aesthete that's objectively good (though I am sure some people do subjectively like it). But it's meant to be sort of a least presumptuous blank state that everyone can radically overhaul. So arguably it's an encouragement for improvement just like everything else in Emacs, which focuses on making the tools for improvement easier.
It's just that "improvement" as a matter of public consensus that everyone can agree on to elect the next blank slate has been to impossible to settle on. But the counterculture here broadly might be extreme reluctance to inconvenience even a minority of existing users, in pursuit of market share/growth.
Nonsense. Many emacs users spend their whole lives inside of it so they're quite sensitive to what is actually an improvement and what is not. The arrival of the various modern completion packages -- vertico, orderless, consult, etc. have been welcomed ... but note that these are all add-on packages. Likewise, all of the "improvements" provided by the OP are a matter of loading and configuring packages.
People who aren't regular emacs users tend not to understand it and are not reliable reporters about the editor or its community.
It's because a lot of us resist the implicit argument that UI changes are automatically improvement when in fact it's just as often regression.
Yep. Look at IntelliJ. It just copied VsCode when it already had a great UI where things were easy to find and consistent. Now it’s got meaningless icons and hides important stuff by default, making it modern but far worse than before. Thank goodness emacs is not trying to chase the latest and stupidest.
There is no better UI for text editing that I have ever come across. I'm not sure why so many people are resistant to the idea that emacs has the correct answer to most UI issues. More programs would stand to take lessons from emacs. Emacs is, in its own right, a very successful piece of software. When eclipse was a thing everyone was saying how great it was vs emacs. But eclipse is gone (I think?) and emacs is still GOATed.
There's a particular kind of hubris from non emacs users (especially those who swear by new ides), that us losers are somehow deprived. We are not and don't need your advice. Nothing to do with counterculture. I tried many editors before I became obsessed with emacs.
>But eclipse is gone (I think?) and emacs is still GOATed.
The 2024 stack overflow developer survey [0] puts Eclipse at over double Emac's market share. If Eclipse is gone, then Emacs is double gone. Emacs struggles to attract and retain new users. This advice is not calling existing Emacs users deprived. It's rooted from the bad defaults giving new users a bad impression of Emac's viability because the default is so bad. If emacs built out proper telemtry they could actually track how the defaults they provide affect the new user experience in order for them to optimize it and figure out what users are looking for.
[0] https://survey.stackoverflow.co/2024/technology
It’s not counterculture. It’s understanding of what’s important. Functionality, discoverability and extendability over opinionated UI/UX that nobody asked for.