That's by design. It must have appealing looks and employ every trick from psychology books to get you to try it and keep using it.
You don't have to be a genius to realize that a for-profit corporation with a $3 trillion market cap, spending millions on building a code editor with no direct licensing model; that they are distributing for "free" is not some kind of unseen goodwill; That shit eventually will generate billions in downstream Azure/services revenue. What is it if not a trivial ROI? It is a "loss leader" in traditional business terms, but a strategic necessity for cloud/services dominance.
VSCode is essentially a Trojan horse for the Microsoft developer services ecosystem - a mental prison that is designed to be easy to get in but hard to escape.
In comparison - vim/emacs have not a single profit motive; their network effect works differently; Yes, there's no entity with trillion dollar market cap to keep the pace with vscode, but no deprecation risks, no corporate pivot that ever is a treat to lock-in your data or your workflow or compatibility with older hardware. Vim & Emacs win by not being a loss leader for anything.
Who can ever predict what happens 5–10–20 years from now? Who can guarantee that some evil CEO wouldn't replace Nadella and secretly start implementing changes in the strategy that would change the essence and the meaning of being a programmer? It is already assumed that every dev has to use GitHub and to know VSCode at least on some basic level today. What if tomorrow your employers would be able to analyze your telemetry data to "measure" your performance? What if the use of anything but VSCode as the code editor would simply be banned?
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.
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.
Double shift, to bring up the pallet, and start typing. Though it also have a ton of shortcuts, and shortcuts can be assigned for almost every command.
Try this: https://plugins.jetbrains.com/plugin/9792-key-promoter-x/
Whenever you don't use keyboard shortcut for any action, this suggests you the available keyboard shortcut.
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.
When you're using it for one, specific purpose, like an IDE for specific language(s), then yes, sure, it may feel like that.
Yet Emacs is so much more. It's not an IDE (but it could be); it's not [the best] source control tool; it's not [greatest] note taking app; it's not an [amazing] mail client; it's not [most beautiful] pdf reader; nor a [feature rich] terminal app; etc. Emacs is not even an editor, to be brutally honest. It's not the greatest concrete implementation of any of these things.
What Emacs actually is - it's a concrete implementation of an abstract idea - a Lisp REPL with a baked-in text editor into it. That, for a second, is an absolutely fascinating commodity. Once you grok the essence of that idea, it's really difficult not to see the extreme value of it.
I'm sorry, I just have hard time to believe anyone who says: "used it for many years... yet abandoned it anyway".
It typically means that they've been using it from a narrow, small focused point of view, without ever exploring the possibilities that "true" Lisp REPL can grant them. I just don't see myself ever escaping Emacs, because there's simply no practical, comparable alternatives to it. Comparing VSCode to Emacs is like comparing it to Thunderbird - you didn't like how Emacs handled your emails and now using something else? Congrats, and that's just fine, only it's not fair and proper comparison by any means.
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)
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.
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?
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.
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.
Nitpick, but emacs and emacs lisp don't seem remotely "functional" to me insofar as expressing computation in terms of pure functions and immutable datatypes. The core datastructures that an elisp program interacts with (buffers, variables) are all mutable and functions (setq, buffer-string, etc) are decidedly impure.
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".
And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…
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…)
It was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
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
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...
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).
I disagree. vim-navigation is imperative for a huge number of devs. It's an amazing, practical, beautiful model. I would've never tried emacs if Evil-mode wasn't so fantastic. And that yet another reason for why vscode never is appealing to me - every one and each vim extension for it has tons of glaring deficiencies.
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
BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
I wonder whether this was intentional or a coincidence, but for others (and maybe you) the "Lisp Machine" was a real hardware architecture unrelated to emacs: https://en.wikipedia.org/wiki/Lisp_machine
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.
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...
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.
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).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.
Only superficially, but not even close in practice. In M-x you can run recursive commands; you have history; you can search through history back and forth; you can scroll the buffer, shrink and widen windows, browse files - all without leaving the M-x menu; you can yank current command or insert directly into the buffer; select multiple commands; act on them; inspect the source; enable tracing; - these are all built-in features.
With some packages you can - export the commands list into a fully functional buffer from which you can still run the commands; you can cycle annotations - show description of the command or keys they bind to; you can display commands in a grid or temporarily flatten the menu for unobtrusive view. You can enable full vim-mode in it - in Emacs, M-x is a fully functional buffer, not some dummy input - I can call the LLM and ask it to find me a command while it's still active.
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.
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.
I say this as a 10 year Emacs user who left for VSCode and Zed because I decided I'd rather discover new modern features when they became useful (VSCode/Zed) rather than having to hunt them down when I became too fed up with the status quo and then have to spend weeks figuring out how to get them working (Emacs). That said, I keep itching to go back for some of the power features. If only it weren't a full time job just maintaining a basic emacs config.
Yeah, that's probably a better analogy.
> If only it weren't a full time job just maintaining a basic emacs config.
I've heard that before, and I don't get it. I might spend 20 minutes a month updating my config, but it's really a set it and forget it thing for me. What are people doing that requires so much work?
edit: i'm on windows
https://www.gnu.org/software/tramp/
I am not sure if it will fit your needs or not.
I do wonder who the target audience is. Sure, this is a nice tryout if you are a VSCoder and want to try emacs. This essentially comes down to new users of emacs and trying to replicate it like another editor. Sounds you are skipping the basics of emacs training.
Perhaps I am wrong, here?
At the end of the day - it's just an .emacs file with the appropriate packages. I would recommend learning those packages individually, allowing you the freedom to express emacs that suits you. If there is something you still like with editors or IDEs like VSCode, you can adapt it.
Emacs is a customisation program!
I have been a C# developer for nearly 20 years (and an emacs user for about the same)
I have been using emacs for practically all languages except for C# with Visual Studio (IDE). However, as the years passed.. have slowly moved over to emacs. By the time .NET Core was introduced (I think VSCode was around this time, also) I realised that I have most if not all tools I need to do some serious .NET work in Emacs. -- Today.. I pretty much use emacs with odd exceptions.
My emacs is very simple. I have my lsp-mode (csharp-ls) as well as the usual magit, yasnippet, etc. With a nice dark theme, I have all I need to navigate about my project/solution. It's funny... when my co-workers see me with emacs they just assume I am "trying to be different" for the sake of it. However, when they watch me.. and without the use of a mouse.. they soon understand why I use it.
I have also added additional functions to create solutions, projects, building, deployments.. all visible from a custom screen.
I dare the author to rebind M-x as well.
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 ...
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.
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"?
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.
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.
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'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.
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.
People who aren't regular emacs users tend not to understand it and are not reliable reporters about the editor or its community.
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 use over 300 hundred packages in my Emacs setup. I honestly not sure if I can install even half of that number of VSCode extensions and expect it to still run smoothly, maybe people do that, I just don't know.
They are called "packages" and not "extensions" for a reason - an extension that e.g., ships with a browser has limitations. In Emacs I can reuse functions of one package in another - in VSCode they have to be explicitly exposed via public API, must be activated in order, they need to be aware of their extension IDs, there's no discovery mechanism - in Elisp, I don't have to deal with any of that.
in Emacs I can explore, modify and bend the source code of any package - built-in or third-party. I can do it in a way that is simply impossible anywhere else. I can granularly change selected behavior of any command without having to rewrite it fully.
That "just works™" part I don't ever buy it - all software is faulty by nature. In Emacs, when something fails - I know exactly how to troubleshoot it, to the specific line in the specific package code; I can profile; debug and trace it. I can modify code in question in a scratch buffer and immediately check how it affects things. Not only I don't have to restart anything, I don't even have to save that code anywhere.
You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing - for what the most "modern" alternatives simply have no answers.
I agree, Emacs is not for the faint-hearted - many people (maybe most) lack the patience required to grok it. Yet make no mistake, those who have tamed this beast are not staying in it simply because "they don't know any better". They know - something better is yet to be made, if ever. VSCode is great, yet still not better.
Learning Emacs has liberated me from experiencing tool-FOMO ever again - I can switch to VSCode without abandoning Emacs, and I can even probably figure a way to control one from another if I get annoyed enough; I just never found a pragmatic reason to use VSCode more. So really, I have zero envy or crave to even become a full-time VSCode user; if anything, I might be forced into it by circumstances, but that's a different story.
Good. For me, VSCode unlikely will ever become anything that I expect from my text editor.
For coding, sure, Emacs may not be great for any specific language except some Lisps, but for plain text manipulation, OMG, Emacs still is the king.
I just can't see it ever replacing it for note-taking - just yesterday I was showing someone "reproducible research" workflow example in Org-mode where I had a source block that sends http requests, then passes that into a bash block where the results get converted to EDN, then connected it to a Clojure REPL, explored and visualized data in it. Name one system that allows you to seamlessly pipe results of one computational block into another, mixing different languages.
Today I made a table with some formulas to calculate some numbers. Does your note-taking app has spreadsheets-capable tables and embedded math formulas?
Two weeks ago I was dealing with a slew of logs coming from k8s pod, and I want it to explore it in my editor - I piped from terminal directly into an Emacs buffer. I can similarly pipe the content of any given buffer into a different unix command.
I control video playback directly from Emacs - it's very nice when I'm taking notes. My pdf documents blend-in into my color theme, which btw. changes based on time of day automatically - Emacs has a built-in solar and lunar calendars.
I search through my browser history and through open tabs directly from Emacs - it's great for finding and grabbing specific piece of text from the browser - so I can put it into my notes.
I rarely need to open Jira in my browser, Emacs understands that "XYZ-12345" is a ticket and shows the ticket description in a tooltip, I can browse its content in-place, same is for RFCs. My Emacs understands that a url is a PR and allows me to review it in-place. It knows when it's looking at a GitHub repo url and allows me to clone it with a keypress, or explore CircleCI logs.
I never type anything longer than three words in any app. I've built a workflow that allows me to quickly move the text into my editor and back into the app. Why would I do it differently? I have all the tools I need - thesaurus, spellchecker, translation, etymology lookup, LLMs, etc.
Finally, once I got the plain text under control, I realized that code is nothing but structured text. I have things like fetching the path to exact line on GitHub, while supplementing the fully-qualified name of the function - my colleagues don't have to guess what they're staring at, they can simply see it without ever opening the link.
I'll install it again. I hope you're happy.
Having a text based Jira frontend seems attractive. (I've actually written myself a cmdline tool that uses Jira API so I don't need to visit the website)