IDEmacs: A Visual Studio Code clone for Emacs
codeberg.org
codeberg.org
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.
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 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
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 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.
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.
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.
The same thing can happen with emacs. There’s a lot of low level interfaces (network, process,…) and some high level ones regarding the UI. Then there’s a lot of utils andd whole software built with those. All modifiable quite easily. As another commenter had put it, you don’t even need to save a file. You just write some code, eval it, and you have your new feature. If you’re happy with it, you add it to your config or create a new module (very simple). So elisp covers the whole range from simple configuration to whole software.
Yet, extending just about any functionality of Emacs for an experienced user is far simpler than in anything else - you can write some expressions in a scratch buffer and change the behavior of any command - built-in or third-party. Not only wouldn't you even have to restart anything - you wouldn't even need to save that code on the file system.
There's a strong correlation between perceived difficulty at the beginning and notable simplicity at later stages. Things that are seemingly harder to grok often open up avenues for clarity later. Conversely, things that seem easy to get into, later often become full of bottlenecks and complexity.
Imagine attempting to replace all the knobs, controls, buttons and switches in an Airbus A380 cockpit with a single touch-based display à la Tesla and claim it's now easier to train new pilots, but you've just made them dependent on a system they don't deeply understand, you've traded 6 months of training for a lifetime of brittle expertise.
I am forever indebted to my younger self for investing some time in understanding the grand ideas behind Vim and Emacs, and never, even once, have I regretted my choices. Rather the opposite - I regret wasting a big chunk of my life chasing popular trends aimed at "intuitive use", "easy start" and "it just works™". I would have never developed the true "hacker's mindset" without them.
Undeniably, there's an immense pedagogical value in tools that make it easy for beginners, but there's also a mental trap there. It's ingrained into human nature - the brain simply doesn't like the grit; it naturally gravitates toward comfort and minimal effort - it just wants to remain lazy. Yet there's a compounding effect of initial investment that pays off later. Sadly, we keep trying to find ways to dumb things down.
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 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.
And honestly, even if that was my job, I wouldn’t want to spend all my time messing around with a fragile, slow, untyped lisp REPL in the first place.
I used Emacs because it helped me get my job done, not because I have any particular affinity for lisp. I truly do not — in fact, I have even less affinity for it now that I’ve wasted so much time making Emacs usable for my purposes.
Yeah, it so totally fair to hear it from a Haskellite, I'm so convinced now... /s
"I have a job to get done, and my job isn't learning category theory, monads, type families, fighting compiler's cryptic messages and pragmas. I don't have any particular affinity for FP. I truly do not - in fact, I have even less affinity for it now that I've wasted so much time making Haskell do basic I/O and fighting the type system for my purposes..."
Even though the take like this maybe viewed as the honest one since Haskell's learning curve is genuinely brutal for practical work, I personally would never say that. I don't use Haskell, but I never regret time I spent trying to conquer it.
You can pretty much assert similar comments as yours about just any tool if you use it without proper understanding of the ideas behind it:
Python: my job isn't screwing around with virtual environments, dependency shit, and pretty useless type hints...
Java: my job ain't wrestling with Spring Boot config files, Maven POMs, and classpath issues...
C++: my job isn't learning the difference between stack/heap allocation, smart pointers, and move semantics...
Rust: my job isn't fighting the borrow checker and lifetime annotations...
Let's be honest, it seems you're mad at Emacs on an emotional level, rather than from educated, pragmatic stance. I admit, over the course of my career path I have felt similarly about different hard-to-learn things, I was like: "I feel like a sucker for not mastering this thing. Other people seem to make it sing. I wasted time and gave up. Now I need to feel like it was the tool's fault, not mine."
Eventually, I learned ways to distill great ideas and borrow them from different tools. I may not use a specific concrete implementation of a given tool daily, yet I find some of the abstract principles behind it appealing.
You have no idea how instrumental Emacs is for my everyday job-to-get-done tasks. It makes me sad to hear you failed to find the same dynamics even after spending a good amount of energy on it. When you're looking for a gray cat in a dark room and there is no cat, you'll spend a lot of time looking. And when you learn that it wasn't about a cat at all, you may end up hating all the cats. Attempting to use Emacs without understanding Lisp is like trying to cook in a dark kitchen. But programmers who dismiss Lisp entirely, are like musicians who refuse to learn music theory because they can play by ear. It's just sad to watch their talent getting lost in unnecessary limitations they've imposed on themselves. It like a talented musician who could understand harmony, composition, structure - but chooses not to. So they plateau. They hit a ceiling where ear alone can't take them further. And devs dismissing Lisp? They might have skills, but they're voluntarily blind to a way of thinking that could deepen their craft.
I wrote a lot of lisp making Emacs work the way I wanted it to. VSCode has been a remarkable improvement. Writing extensions for it has been a breeze. I have zero interest in going back.
Share the Emacs packages you wrote. I'm saying this unironically - someone might be interested to keep improving them, maybe they'd find some interesting ideas to extract from them. Don't be like some ungrateful jerk who benefited from communal work for years when it suited them and then has nothing to leave but grumpy resentment when they're done.
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.
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 just want to share my anecdotal, personal story. I used IntelliJ professionally for almost a decade. I learned some advanced and undocumented features. I've collaborated with Jetbrains team members to help improving the features. It felt like I work for them. I still occasionally receive YouTrack notification emails for the bugs I posted circa 2009, that are still not fixed today, btw.
IntelliJ is to blame for why my transition to Emacs took me two years - I carried the fear of investing too much into a new thing. I feared of liking it, and someday not finding some features I was so attached to in IntelliJ. I was scared that I will be intellectually and emotionally "locked in", while I was already vendor locked-in and condemned to be using IntelliJ forever.
I was so wrong - not only have I found everything I needed, and more, I have developed a true hacker's mindset. Honestly, the only regret I still carry today, even after years of Emacs use, is that I did not attempt to learn it sooner. I no longer experience FOMO - I can easily pick up IntelliJ whenever I want again, I just haven't found a real, pragmatic reason to do so. In fact, I do fire it up on occasion, just to get the feel of how things evolving there, to steal some good ideas, etc.
> and IdeaVIM
Gary Bernhardt famously said - "There's no such thing as vim-mode". And to the degree, he was right - pretty much every editor/IDE that tries to integrate Vim features invariable ends up having glaring deficiencies. IdeaVIM is good enough, but only to the point - for an expert vimmer it may feel annoying. VSCode vim experience is similar, and Sublime as well - there's really no good comparison between them to say which one is really "better", they all have a spectrum of weird, quirky behaviors. There's one notable exception - Evil-mode in Emacs is fantastically good - sometimes you even forget that it's not a built-in feature, but a third-party extension, an afterthought.
> shortcuts can be assigned for almost every command
In Emacs, you can bind keys to anything, conversely - everything is a command - every keypress, every mouse click and mouse-scroll. And since Emacs is inherently a modal editor, you can do stuff like binding commands to a double, triple, etc. keypresses. Like for example, when I'm typing fast, to autofix most recent typo I'd just tap comma twice - this is just one example of unbelievably fast way to stay focused.
Most devs, once they find their favorite tool would settle with it and don't even explore other options. "I don't have time for that.", "I don't want to be building my editor", "I am already so good with what I have, why?", they would say. My suggestion is to always stay skeptical of current choices and curious about unknown. It's not the concrete implementations, but rather abstract ideas that may grant some surprising and unexpected benefits.
> IntelliJ is to blame for why my transition to Emacs took me two years ...
It was a bit opposite for me, I jumped around so many editors, and, then I fell in love with VIM, spent so many hours to get the config that meets my need, dissed many Emac users. And, now after many years, as I grew, I realized, these are tools, and at the end, it's all on the user who makes it click.
I use both IntelliJ and (n)vim almost side-by-side, every day, when I am on my main desktop, I am on IntelliJ, when I am connecting through ssh, I am on NVIM. I use NVIM, because it's LSP, and treesitter's highlight is really good. But in any other case I am using VIM. I even wrote this reply on VIM.
I could make VIM work like NVIM, sure, but does it worth the trouble, when I can just use LazyVim? nah ...
> Gary Bernhardt famously said - "There's no such thing as vim-mode ...
True, most of the software can't replicate how wonderfully VIM works. I have had my moments with IdeaVIM, and resorted to VIM, but, again, there are things that IntelliJ does so good, and IdeaVIM scratches a vim sized itch. IdeaVIM makes IntelliJ more useful for me.
And, with these tools together, I can get a lot done, where it would be too inconvenient if I was doing it in VIM, or too annoying if I was doing it in IntelliJ without IdeaVIM.
> In Emacs, you can bind keys to anything, conversely ...
Certainly, you can be faster with keyboard, and It is possible to do the same with IntelliJ + IdeaVIM. Additionally, with IntelliJ, I can quickly navigate my database, write queries, or manage Docker containers without going to another terminal or app. Not having to change window/app is extremely helpful for me to stay focused.
And, I have not found any cli based db tool that is as good as IntelliJ's one.
> Most devs, once they find their favorite tool would settle with it and don't even explore other options ...
True, I used to encourage people towards VIM, converted one or two, but at the end, I realized, it's their choice, and some might even have good reasons for their choice.
I can show them the magic, but it's always their decision to pick it up.
I am a die-hard vimmer. I just one day woke up and realized that Emacs vims better than Vim. Seriously though - it's not about concrete implementations, it's all about the [abstract] ideas.
I use vim navigation everywhere - in my editor, my browser, my terminal (I use nvim too), my WM, remote sessions. I control my music, video-playback, app switcher - all, using mostly just home row keys. I never need to touch arrow keys and rarely have to reach for the mouse.
Idea of vim navigation is an absolutely brilliant, beautiful, practical model, it speaks to me and I have zero reasons for not using it. What keeps me with Emacs is another immeasurably brilliant idea - the idea of practical notation for lambda calculus, which is known as Lisp. Lisp probably can be crowned as one of the most important ideas in computer science. It's just hard to think of anything more influential than Lisp.
There's a notable shared trait between these two - they both entail tacit knowledge. You're probably well aware of what I'm hinting at. You see, trying to teach someone who never rode a bike is challenging for a similar reason. You may show them countless videos, explain how gyroscopic effect and caster effect keep the bicycle stable, you can draw diagrams and try to inspire them with names of all famous people who loved riding - none of it can explain the simple joy of an ordinary bike ride on a straight line. Until they've tried for themselves, nothing will ever make them feel what they can never unlearn later.
> I use both IntelliJ and (n)vim almost side-by-side
I perfectly pictured my own younger self - I absolutely had maintained the same setup not too many years ago, before diving into Emacs. And then it became three things side-by-side. Eventually, I had to stop this madness and forced myself to use only one. I made a promise that instead of reaching to the familiar and cozy confines and warmth of WebStorm, whenever I had to get something done, I would try to google and find ways to achieve the same things in Emacs. I really wanted to figure it out and make the decision once and for all. My plan was to time-box that experiment for a week, fully expecting that in the end it will replace Vim, but certainly not WS. After a week I decided I liked it and I wanted to keep going. Two months later I realized - I had not had to run WebStorm even once. Five month later I decided not to extend my license for next year, but it was never about the money.
Keep finding new bicycles to ride. Even when you don't feel like it, and especially when it feels kinda scary.
But, when you keep changing your bikes, and start fiddling with the mechanics of it, you forget, what made it worth in the first place! What was the thing that gave you the pure joy.
PS: Using nvim and IntelliJ(Ultimate) side by side is for a personal reason. I have to be away from my main desktop for a really long time. So have to SSH into my desktop using a Surface Pro 3 (Running Linux) to work. It's a really portable setup, and works well as a thin client. And it is an experiment to fully utilize CLI tools, to get my work done.
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)
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.
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.
It's not some technical impossibility - I think it would make sense to make this possible, at least in GUI Emacs. I suppose there was never a strong incentive to tackle this problem.
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…
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.
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.
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.
My comment is an honest reflection of long-time Emacs usage. When I started, years ago, I just couldn't wrap my head around the fact that there were no tabs for every file anymore - the concept that was seemingly ingrained into my programmer's brain - almost in every IDE/editor I used before Emacs, I had tabs and a navigational panel on the side. I complained and demanded my tabs, asked on forums and called it "bullshit", when people calmly told me that I truly don't need them. Later I realized - they were right.
Slowly I learned that the wise choice is to remove any distractions - you don't need a minimap, side-panels, complicated modelines, and even line-numbers shown all the time. All that can be activated purposefully, on demand and then toggled off again. These "visual clues" are in fact not so much even distractions but micro-bombardments of your brain neurons - you think they are helping, while in fact they are slowly eating up your neural capacity, to the point that the brain just stops even paying attention to them and they become almost useless waste of your screen estate.
I'm not saying that this all generally true for every case and every user - some prefer certain ways, and it's great that we have a system that is able to satisfy any whim, but it's worth sometimes questioning yourself - am I enslaved by my own mental habits?
However, what then we'd do with nearly half-a-century history of Emacs? There are so many packages out there - it's insane to ever think we'd have to re-implement all that ginormous constellation of functionality in Common Lisp. Until we can find some quick way to translate them there, I honestly don't see any practical possibility for the migration.
Who knows, maybe agents will get so good and someone will eventually figure out a path; until then, Emacs is to remain - with all the good and bad parts.
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).
The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
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 too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
> I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
tbh, I can't take any experienced programmer seriously if they never even tried learning at least some basic vi-navigation commands. I'm like, "what? have they never used `sed`, `less`, `more` or never read man pages? have they never logged to a remote machine? why kind of a coder doesn't know any of this shit?" I mean I get it, it's not universally appealing to everyone, some prefer not to bother. But not knowing it at all? That's weird to me. And yes, I agree - If you're making an editor for coders (standalone, embedded, web or native), modal navigation must be possible.
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.
Emacs is single threaded and can't offload any elisp code. Even the stuff it can offload as background OS processes report in to the main loop and share time with editing, so a chatty background process can and does frequently lock up Emacs. So I'm surprised that VSCode, whose runtime is better suited to async jobs, ever feels slower than Emacs.
I use Emacs for managing files (with Dired) running shell commands, bookkeeping, keeping notes and chatting with LLM services.
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
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.
Vim forever I guess. Im typing on a full split with cherry reds (very soft). What are you on?
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...
Keysets or chorded keyboards have been around since The Mother of all Demos, but never really seemed to have caught on. It makes sense to me to put them at your feet to chord some common actions or modifiers.
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?
15 years ago I was in the same boat as you.I just had a set it and forget it config. But about 6 years ago I had to start adding addition languages support to my config, and started having to switch machines at work every year or so.
Emacs package manager has always been abysmal at reusing an existing config on a different machine, and always required significant updates to the config for the latest versions of the packages (which frequently have/had breaking changes every coupe years). So it became a config update every year or so, that would take a couple days at minimum.
Then the language support had to be addressed. With the couple days of updating every year or so, I start eying what other solutions are providing, especially since I was delving into new areas and toolsets. A few years ago simple dumb syntax and identifier fuzzy completion stopped being sufficient and table stakes became intelligent context-aware autocomomplete. Emacs setup for that was incredibly bad and has been extremely poor for years up until very recently. Only in the last year-ish has actual working LSP support finally been added and isn't bolted into a system that can barely cope. That means there was literally a gap of a few years where Emacs at best failed to meet the minimim to even be considered as a primary editor. Even still, the setup is very manual to get even the most basic integration.
A similar rush of features is now pretty normal in editors, and Emacs is simply not keeping up. It's now a question of trade offs: how much do I want those crazy editing features of Emacs, and how many one-click support and integration features that are standard across almost all competitors am I willing to go without or spend hours every couple weeks setting up?
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.
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 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.
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.
I can't tell if this is an attempt at humor or something people actually believe
Good God, NEIN!
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 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.
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 ...
In comparison most other languages are 'closed' - e.g., C is a closed language. Its spec is finite and fixed (C99, C11, C17, etc.). You can genuinely master it: all keywords, all standard library functions, all undefined behaviors, all edge cases. There's a ceiling.
Lisp is unusual, The language itself is a tool for language-building. Lisp is 'open'. There's no canonical "complete" set of what exists. Thus there's never completion or "mastery"
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.
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.
But those are not the users who choose Emacs in the first place. Emacs is made for customization.
Besides, there are many preconfigured distributions of it, such as the one discussed here, which can effectively be used as the defaults, if you don't like the ones shipped OOB.
> I consider emac's bad deals an existential issue that significantly hurts adoption.
Well, I reckon you're wrong. Emacs in all of its incarnations has been in use for nearly half a century, and its adoption has never been greater. Some people will point to low percentages in developer surveys, but that is the wrong metric to focus on. Its usage will never reach mainstream numbers, which is probably for the best, but it will continue to be enjoyed by enthusiastic users for a long time to come.
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'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.
Yes, Emacs is not popular, but if you look deeper, you may find unsurprisingly that most Emacs coders are strong developers. That correlation isn't coincidental - you don't stick with Emacs unless you're willing to learn; it effectively teaches you about Lisp, extensibility, and programming in general.
Yet, they are not talking about general popularity of editors among devs, but about people who ever tried Emacs - the argument is that the majority of them try, fail and abandon it. For which obviously there's no polemical (or otherwise) data points.
I bet this is some kind of a known issue, but that just reinforces my original point above.
edit: yeah, here it is: https://bugs.kde.org/show_bug.cgi?id=509871
I mean, how it's not an Emacs issue if it only happens with emacs?
I never had what you describe. The variability there could be almost random - which version of Emacs you're installing? How are you installing it? Are you trying to build it from source? What renderer are you using - there are several: Lucid, Motif, GTK, NS, W32, Haiku, Android, Cairo, Pgtk. Perhaps it's installing different renderer instead of using pgtk. Maybe it's not a bug with Emacs but with the package that bundles it for your distro?
> how it's not an Emacs issue if it only happens with emacs?
It does seem to be an Emacs issue. But it is a specific issue that happens on the combination of your hardware and your OS configuration.
For example, macOS emacs always starting at the bottom of the window stack instead of the top. macOS emacs having different font notation than Linux emacs, so maintaining common config is hard. Terminal emacs -nw having its own set of rules, and M-x needs to be addressed with ESC x. Etc, etc.
The tradeoff is that Emacs does let you handle it all - you're not forced to accept platform defaults like in some editors. Most editors have their UI/behavior largely baked in by the platform. You can customize colors and keybindings, but the fundamentals - window management, font rendering, how system keys work, terminal integration - are mostly dictated by whether you're on Mac, Windows, or Linux.
So when you have mac Emacs behaving differently than Linux Emacs, it's not because the software forced you into that corner - it's because the underlying systems are different and Emacs exposes that difference rather than hiding it behind a unified abstraction layer.
Emacs gives you the rope to make things consistent across platforms, but also the rope to hang yourself. Other editors pre-tie the knot for you.
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.
You say like it's some kind of feature, but for me it sounds like a potential for name clash, and using private API which is prone to change/break.
> You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing
The thing is that is was VSCode which has brought us LSP, not "emacs hackers". It was VSCode which has brought us LLM Agent mode. All editors are catching up to VSCode, not the other way around.
LSP, LLM, ssh/docker/podman remote development, what's the Emacs answer to those? (I mean, nowadays vim+emacs have their own LSP clients built-in, years after VSCode)
Oh, you just have no idea. It feels absolutely empowering and immensely liberating to have access to EVERY single line of code running and affecting your system editor. Whenever I need to solve a problem, I don't need to ask permissions, send PRs, dig through API documentation, google for answers, yell at LLM for not giving me answers - I can modify any behavior of any function on the fly and just move on. All that "it just works™" promise of other editors quickly evaporates when I, as a programmer, feel out of control of whatever happens on MY computer. Sure, yes, there's always a possibility that my "stupid hacks" just break for no apparent reason. Except, it rarely happens in practice, and when it does, I know how to quickly fix or put a workaround, because I precisely can pinpoint the exact line of code. Last time when something broke and it took me more than ten minutes to figure it out was about two years ago - the combination of multiple upstream updates and my lousy customization on top confused me for some time - it's all about trade offs, I'm happy to spend 15 minutes once every few years to fix some shit, if that gets me complete and total control over my environment.
I'm a hacker, not a florist - I want precision and complete transparency, not pretty buttons. I don't want any magic - I can't trust some extension to "just work" on a button click, without precisely knowing what it installs, where, and to what extent.
> what's the Emacs answer to those?
Ah, just like I said before, you're talking about things as if you're staring at the surface of the calm water of a lake. Except for an ocasional splash, it may seem lifeless to you, yet you don't have the faintest idea of its depths or what lies beneath.
There's currently an implosion of different LLM packages for Emacs - gptel, gptel-agent, ECA, agent-shell, claude-code, claude-code-ide, monet, claude-repl - and numerous others I haven't even heard of, these are just off the top of my head.
Emacs community may not be big enough and may lack incentives to constantly innovate, but they have no problem borrowing ideas from other places.
> All editors are catching up to VSCode
Wake me up when they figure out things like indirect buffers and executable source blocks in different PLs that can pipe data into one another, or when someone uses VSCode to control their window manager. Or when I can use literate programming to manage my dotfiles. And I haven't even gotten to the REPL part, even with Joyride it still falls short - there's no "I can hook to everything and redefine anything" in Code.
LSP is a great thing to have, but it's actually much less capable than something like SLIME. If you've used SLIME, you'll see there's no comparison. LSP is a lot better than the nonsense I had to go through to get Java completions in the early 2000s, and I'm thankful to have it.
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)
Not until you are happy, it makes me sad when Emacs makes people sad for whatever reason.
> Having a text based Jira frontend seems attractive
Yeah, I can't even start describing it, proly gonna make a video or something.
Like I would get the cursor on a plain text like "XYZ-34857" - it shows me the popup with the ticket description. If I ever would want to add the status - todo/done/etc., or assignee, or something else to the popup - that's a simple change. From there I can browse the ticket, I can convert the string to a url with the description - it's smart enough to recognize the mode I'm in and makes the proper markup. I can generate a branch name based on that ticket description, etc.
To clarify - anyone can do the same, I'm just delegating the task to go-jira - a cmd-line tool. You don't really need Emacs for that - it's doable in neovim and vscode and even in vanilla terminal. Yet the simplicity of making it work via Lisp is just unmatched experience. These days I would ask a model, it would build a prototype, I would iterate on it on the fly. It feels like playing a video game. I don't even blink - I see a problem - I'd start writing some Elisp in a scratch buffer. I keep hearing "I don't have time to tweak my config", but I'm not really tweaking anything - I'm just hacking solutions for the real problems that arise - I'm just being the definition of a programmer. And no need for sophisticated packages - my Jira requirements for now are satisfied with simple hacks in my config:
https://github.com/agzam/.doom.d/blob/main/modules/custom/ji...