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.
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 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.
Familiar UX is not the kind of multiplier. Learning Lisp REPL idioms is the multiplier. Selling Emacs with "easy" may have adverse effects in the long run - it sets the wrong expectations from the get-go. Every Emacs discussion typically gets a few "I tried Emacs for a long time and it just didn't work for me..." type of comments. When you dig deeper, you typically hear that they've been trying to use mostly the editor, ignoring much of the Lisp functionality. Unlocking the power of Lisp is what gets you into "turbo" mode in Emacs.
I get it - Elisp is an absolute opposite of being easy and intuitive, even experienced coders who already used modern Lisps like Clojure often complain that it just doesn't feel comfortable. Common Lispers don't like it either. Schemers have little love to share for it as well - it's a common theme.
Unfortunately, that's the Lisp we have, and until we figure out a better alternative, we have no choice. FWIW, it's still a Lisp, and it's still far better than anything else that's non-lispy. The simplicity and dynamism of Lisp is what allows you to quickly move forward, to build things that defy expectations, extend things beyond common sense when required.
We have many examples of when people with no programming background grind through the Elisp tutorial without any prejudice and start building things that eventually turn into legendary packages. Perhaps it's more valuable to cater "beginner Emacs experience" for these kinds of personalities, rather than trying to appeal to reactjs/springboot/django divas with "decades of programming experience" that demand tabs, sidebars and minimaps; twist their faces whenever they have to stare at Elisp stacktraces and complain that "Emacs doesn't look modern enough"?
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.
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?
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...
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.
To be clear, this plugin is only a keymap, and just extends the built in Emacs-style keymap option of VSCode. If you did much/any mapping of any keys in Emacs, or are looking to expose more Emacs-like features, you're SOL. VWCode is simply unable to support most Emacs editing features without a significant engine expansion, and that's beyond the ability of plugins to add.
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?
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 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.
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 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 did exactly the same, though I wasn't an Evil mode user. I quickly found VSCod(e|ium) lacks the internals to even do many of the basic useful things of Emacs.
BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
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.
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.
Does not take any coding ability configue it. Out of the box you can search for any setting and even if you edit the json config directly you get autocomplete.
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
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.
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.
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.
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.
38 comments
[ 0.12 ms ] story [ 3138 ms ] threadIt was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
I dare the author to rebind M-x as well.
Familiar UX is not the kind of multiplier. Learning Lisp REPL idioms is the multiplier. Selling Emacs with "easy" may have adverse effects in the long run - it sets the wrong expectations from the get-go. Every Emacs discussion typically gets a few "I tried Emacs for a long time and it just didn't work for me..." type of comments. When you dig deeper, you typically hear that they've been trying to use mostly the editor, ignoring much of the Lisp functionality. Unlocking the power of Lisp is what gets you into "turbo" mode in Emacs.
I get it - Elisp is an absolute opposite of being easy and intuitive, even experienced coders who already used modern Lisps like Clojure often complain that it just doesn't feel comfortable. Common Lispers don't like it either. Schemers have little love to share for it as well - it's a common theme.
Unfortunately, that's the Lisp we have, and until we figure out a better alternative, we have no choice. FWIW, it's still a Lisp, and it's still far better than anything else that's non-lispy. The simplicity and dynamism of Lisp is what allows you to quickly move forward, to build things that defy expectations, extend things beyond common sense when required.
We have many examples of when people with no programming background grind through the Elisp tutorial without any prejudice and start building things that eventually turn into legendary packages. Perhaps it's more valuable to cater "beginner Emacs experience" for these kinds of personalities, rather than trying to appeal to reactjs/springboot/django divas with "decades of programming experience" that demand tabs, sidebars and minimaps; twist their faces whenever they have to stare at Elisp stacktraces and complain that "Emacs doesn't look modern enough"?
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'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.
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
BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
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.
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.