Emacs for programming is definitely one important use case. This tool seems to focus on that use case, though I think I can get 75% of it by just using Emacs keybindings with regular VSCode.
But Emacs is so much more than an ‘IDE’. I realize some don’t like the Emacs approach of ‘here’s a box of parts and tools, build it the way you want’, but that’s the point of Emacs.
Besides the functional approach, of course, there is the philosophical stance: freedom.
Emacs is an elegant weapon from a more civilized age. But some people prefer blasters, and that’s okay.
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.
Here's the thing (as someone who did Emacs for a year and then gave it up)
The possibility and ease of interoperability with other general program styles is far more important that the idea is given.
Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)
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).
With emacs, you can just use “customize” (for options) and “M-x” (for commands) and never care about anything else. Yes, it’s not as visible as vscode, but it’s very much the same thing.
But once you learn elisp, then you have the power of a full VM at your disposal and not wait for a plugins to exist and hopefully implement your workflow. And adhoc integration (like having ticket number in comments be clickable) is not easily feasible.
Yeah, now see, you need to do that for every programming language, or tool for vscode.
With Lazyvim you get all at once. And you can ignore many plugins if you want,
Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster
but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities
>Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode.
I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled.
I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.
No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim.
With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.
There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool.
Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.
I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life.
Likewise, I find VSCode overstimulating and, for lack of a better word, rude.
I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around.
I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.
>that thing is overwhelming with all its popups, hovers, sidebars etc.
I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.
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 ..
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.
Long-time (25+ years) Emacs user. The first thing I do on a new installation is turn off the GUI features (like, menus and toolbars) - no-one I know who uses Emacs uses the mouse.
If you use an editor or IDE at work for a year, you might work with it for a thousand hours that first year alone. But a noisy GUI like VSCode's is optimized for just that first 30 minutes of playing around.
For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
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
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.
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.)
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.
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.
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…)
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.
Should've probably mentioned it before but it actually used a dual-license model by having an MIT version that lagged behind upstream for 18 months (could be found in oni2-mit repo). During last month when development stopped it was fully re-licensed under MIT (hence oni2-mit repo no longer exists).
As a 15+ years emacs user the only item on my wishlist is client-server remote editing mode similar to that of vs code. Then I can go back to using emacs on cloud VMs. Does anyone know a solution to this that works as good as VS Code even when your latency is high? Hopefully, I will be pissed off with all the weird configuration flags of VS Code enough to write one myself ;-) To be fair its python integration is quite good at least for the usual stuff.
1) Run Emacs on your local machine and use Tramp to edit the remote files
2) Run Emacs on the remote machine with the files you're editing. This likely means running in the terminal itself (emacs -nw or requivalently emacs -t).
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.
Next up, how to make your Ferrari into a Fiero clone.
Seriously, though, this seems kind of counterproductive. The power of Org mode and some of the other tools in Emacs comes from being integrated into the rest of Emacs and the synergies from Emacs idioms and concepts working everywhere in Emacs.
Just my opinion, but the time spent learning this front end would be better spent just learning the Emacs UI. It's really not that difficult, and pretending you can't learn it just makes it more difficult in the long run.
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 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.
> 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.
I prefer both Vim and Emacs over VSCode, but I teach intro programming at a university and use VSCode in the lectures.
VSCode is actually quite decent if you use it as a keyboard-driven thing with a distraction-free interface. By the former, I mean that Cmd-Shift-P does the same as Emacs’ M-x, and from the keybinding hints you quickly learn any recurring useful bindings (or can change them under Cmd-K Cmd-S when they feel bad). By the latter, I mean that nearly every UI element can be disabled (activity bar, tab bar, status bar, scroll bar, most buttons, indent guides, gutters, etc.) and if you spend 30min disabling the fluff it looks as minimal as Emacs. You don’t really need the UI elements if you learn Cmd-Shift-P and basic keybindings, which as an Emacs user you’ll pick up in a week.
Not trying to sell VSCode here, as I said I don’t prefer it myself. I really tried to switch some times, but I don’t like the Microsoft monoculture nor the importance of proprietary plugins (like remote development and pylance), and an Electron app usually has some weirdness when it comes to font rendering, UI bugs, etc. compared to native or terminal apps.
But if you have to use it, it’s actually not bad if you approach it in the same way you’d approach Emacs: Call functions with Cmd-Shift-P (can rebind to M-x if you want), and invoke more common functions via keybindings instead of UI elements.
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
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?
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...
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.
I've got a whole labouriously created setup for my emacs that is roughly equivalent to my RustRover setup in terms of capabilities (though not [mostly] in terms of keybindings because my fingers are fine with default emacs bindings). And I still barely use it, and I continue to fire up RustRover constantly.
Because it just never feels snappy and fluid and responsive and stable. RustRover is a slow dog at times, but even it outperforms emacs for a lot of things.
The lack of proper multithreading in GNU Emacs is a problem.
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 ?
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
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.
My comment is discussing the defaults. Most users will use the defaults and not customize their editor, especially if they are just using it for the first time. The defaults are important.
The single threaded issue is a problem, but one that can be somewhat worked around. I consider emac's bad deals an existential issue that significantly hurts adoption.
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.
> 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.
I can't tell if this is an attempt at humor or something people actually believe
It’s not counterculture. It’s understanding of what’s important. Functionality, discoverability and extendability over opinionated UI/UX that nobody asked for.
Emacs for programming is definitely one important use case. This tool seems to focus on that use case, though I think I can get 75% of it by just using Emacs keybindings with regular VSCode.
But Emacs is so much more than an ‘IDE’. I realize some don’t like the Emacs approach of ‘here’s a box of parts and tools, build it the way you want’, but that’s the point of Emacs.
Besides the functional approach, of course, there is the philosophical stance: freedom.
Emacs is an elegant weapon from a more civilized age. But some people prefer blasters, and that’s okay.
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.
Here's the thing (as someone who did Emacs for a year and then gave it up)
The possibility and ease of interoperability with other general program styles is far more important that the idea is given.
Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)
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).
With emacs, you can just use “customize” (for options) and “M-x” (for commands) and never care about anything else. Yes, it’s not as visible as vscode, but it’s very much the same thing.
But once you learn elisp, then you have the power of a full VM at your disposal and not wait for a plugins to exist and hopefully implement your workflow. And adhoc integration (like having ticket number in comments be clickable) is not easily feasible.
Yeah, now see, you need to do that for every programming language, or tool for vscode.
With Lazyvim you get all at once. And you can ignore many plugins if you want,
Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster
but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities
>Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode.
I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled.
I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.
No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim.
With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.
There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool.
Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.
I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life.
Likewise, I find VSCode overstimulating and, for lack of a better word, rude.
I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around.
I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.
>that thing is overwhelming with all its popups, hovers, sidebars etc.
I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.
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 ..
I’ve been using emacs for very many years, and have a configuration that has evolved over a decade.
I was able to pick up VSCode in an hour. It’s not complicated. I’m using it with the Haskell extension and it’s great.
Honestly, I’m tired of Emacs’ performance, bugs, complexity, and poor UI that requires an enormous amount of hacking to make a usable IDE.
VSCode is a breath of fresh air. The only things I’m not using it for are languages that don’t have extensions yet — Cryptol and SAW.
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.
Long-time (25+ years) Emacs user. The first thing I do on a new installation is turn off the GUI features (like, menus and toolbars) - no-one I know who uses Emacs uses the mouse.
VSCode users, especially new ones, do. The best property of Emacs is that you can modify the lisp machine to do whatever you want.
If you use an editor or IDE at work for a year, you might work with it for a thousand hours that first year alone. But a noisy GUI like VSCode's is optimized for just that first 30 minutes of playing around.
For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
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…
So we all agree we need Emacs 2.0™, rewriting both the UI and the guts? /j
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
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.
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.)
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.
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 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…)
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.
Should've probably mentioned it before but it actually used a dual-license model by having an MIT version that lagged behind upstream for 18 months (could be found in oni2-mit repo). During last month when development stopped it was fully re-licensed under MIT (hence oni2-mit repo no longer exists).
As a 15+ years emacs user the only item on my wishlist is client-server remote editing mode similar to that of vs code. Then I can go back to using emacs on cloud VMs. Does anyone know a solution to this that works as good as VS Code even when your latency is high? Hopefully, I will be pissed off with all the weird configuration flags of VS Code enough to write one myself ;-) To be fair its python integration is quite good at least for the usual stuff.
Two approaches might work here:
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.
Next up, how to make your Ferrari into a Fiero clone.
Seriously, though, this seems kind of counterproductive. The power of Org mode and some of the other tools in Emacs comes from being integrated into the rest of Emacs and the synergies from Emacs idioms and concepts working everywhere in Emacs.
Just my opinion, but the time spent learning this front end would be better spent just learning the Emacs UI. It's really not that difficult, and pretending you can't learn it just makes it more difficult in the long run.
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 ?
Or an accordion! https://x.com/ykarikos/status/1038145486618861573
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.
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.
> 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.
I prefer both Vim and Emacs over VSCode, but I teach intro programming at a university and use VSCode in the lectures.
VSCode is actually quite decent if you use it as a keyboard-driven thing with a distraction-free interface. By the former, I mean that Cmd-Shift-P does the same as Emacs’ M-x, and from the keybinding hints you quickly learn any recurring useful bindings (or can change them under Cmd-K Cmd-S when they feel bad). By the latter, I mean that nearly every UI element can be disabled (activity bar, tab bar, status bar, scroll bar, most buttons, indent guides, gutters, etc.) and if you spend 30min disabling the fluff it looks as minimal as Emacs. You don’t really need the UI elements if you learn Cmd-Shift-P and basic keybindings, which as an Emacs user you’ll pick up in a week.
Not trying to sell VSCode here, as I said I don’t prefer it myself. I really tried to switch some times, but I don’t like the Microsoft monoculture nor the importance of proprietary plugins (like remote development and pylance), and an Electron app usually has some weirdness when it comes to font rendering, UI bugs, etc. compared to native or terminal apps.
But if you have to use it, it’s actually not bad if you approach it in the same way you’d approach Emacs: Call functions with Cmd-Shift-P (can rebind to M-x if you want), and invoke more common functions via keybindings instead of UI elements.
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
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?
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...
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
I've got a whole labouriously created setup for my emacs that is roughly equivalent to my RustRover setup in terms of capabilities (though not [mostly] in terms of keybindings because my fingers are fine with default emacs bindings). And I still barely use it, and I continue to fire up RustRover constantly.
Because it just never feels snappy and fluid and responsive and stable. RustRover is a slow dog at times, but even it outperforms emacs for a lot of things.
The lack of proper multithreading in GNU Emacs is a problem.
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/
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...
That screenshot is super pretty. Very impressive!
Thank you!
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
I like to express my loyalty to the emperor of man and call this heresy
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.
The data shows VS Code is used by double digit % of developers, whereas Emacs is less than 1%, I think that qualifies for most.
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.
My comment is discussing the defaults. Most users will use the defaults and not customize their editor, especially if they are just using it for the first time. The defaults are important.
The single threaded issue is a problem, but one that can be somewhat worked around. I consider emac's bad deals an existential issue that significantly hurts adoption.
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
> 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.
I can't tell if this is an attempt at humor or something people actually believe
It’s not counterculture. It’s understanding of what’s important. Functionality, discoverability and extendability over opinionated UI/UX that nobody asked for.
Well people will vote with their mouse clicks, and they have, < 1% of devs use Emacs vs VS Code which is probably 20-30x.