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.
VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.
> VSCode is familiar in its UX
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?
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity.
I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result.
My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults.
For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
With emacs, you can just use “customize” (for options) and “M-x” (for commands) and never care about anything else. Yes, it’s not as visible as vscode, but it’s very much the same thing.
But once you learn elisp, then you have the power of a full VM at your disposal and not wait for a plugins to exist and hopefully implement your workflow. And adhoc integration (like having ticket number in comments be clickable) is not easily feasible.
Your argument is like... "once you learn C++ you have your whole processor at your disposal, you don't need to wait for any software because you can write it yourself."
That just highlights some confusion about Emacs. It’s more akinto Unix and the shell as a whole. That’s why I said VM. If you know perl and have a whole host of utils from a unix box, you can script the workflow you want quite easily, especially if you have access to the cpan libraries.
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.
Yeah, now see, you need to do that for every programming language, or tool for vscode.
With Lazyvim you get all at once. And you can ignore many plugins if you want,
Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster
but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities
>Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode.
I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled.
I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.
No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim.
With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.
There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool.
Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.
You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.
> incredibly easy compared to getting them to edit some vim/emacs config
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.
I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life.
Likewise, I find VSCode overstimulating and, for lack of a better word, rude.
I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around.
I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.
IntelliJ shines when you use the command pallet, keyboard shortcuts, and IdeaVIM
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.
IntelliJ is an amazing feat of software engineering, there's no denying that. I'm not saying that to make you (or any other WebStorm/Pycharm/etc. user) feel better - I know that from years of dedicated use.
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.
No issues here, except for you being an Emacs user :D
> 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.
> No issues here, except for you being an Emacs user
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.
Ah, bicycles, something that I love so much. Yes, agreed, someone who never rode will never realize how amazing it is feel the air in your face, the gentle sound of the tire rolling. I miss it so much.
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.
I’ve been using emacs for very many years, and have a configuration that has evolved over a decade.
I was able to pick up VSCode in an hour. It’s not complicated. I’m using it with the Haskell extension and it’s great.
Honestly, I’m tired of Emacs’ performance, bugs, complexity, and poor UI that requires an enormous amount of hacking to make a usable IDE.
VSCode is a breath of fresh air. The only things I’m not using it for are languages that don’t have extensions yet — Cryptol and SAW.
> requires an enormous amount of hacking to make a usable IDE.
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.
I have a job to get done, and my job isn’t screwing around with my Emacs configuration.
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.
> I have a job to get done
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.
Yikes. I’ve spent 40 years in this industry. My work is in formal verification. My comprehension isn’t the problem here.
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.
> I wrote a lot of lisp making Emacs work
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.
That's genuinely wild, man.
In what sense? I apologize if I offended you. Just to be clear - don't share your config, experiments, packages or whatever with me specifically - simply consider making them public. Don't let the years of accumulated wisdom (whatever it adds up to) go waste. Emacs is not "a product", it's a "shared enterprise" and collective endeavor. Of course, it's not really "free" - just like everything, it has a price - it requires patience, dedication and time from every participant. You've mentioned using it for years, which means you've contributed to the cause. You've decided to move on - your reasons are your own. I'm not asking you to donate, volunteer, or speak about it either way. Do what you want. But for a moment, perhaps consider this with wonder: how many remarkable things have we humans collectively created that require no payment whatsoever, yet grant us the freedom to do things on our own terms? Projects like Emacs and Vim/Neovim are like free-for-all, unrestricted gardens. And that's why I get vexed seeing stuff like: "used it for years - getting tired of it...", etc. Reflections like that are akin to shitting all over the neck of those imaginary gardens, making them less desirable places for curious newcomers. I'm not telling you to not criticize, please do, but perhaps with consideration - tell it with constructivism. Allow those gardens to grow. They will most likely outlive your pondering - positive or otherwise, and mine and those of many more generations.
Here's the thing (as someone who did Emacs for a year and then gave it up)
The possibility and ease of interoperability with other general program styles is far more important that the idea is given.
Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)
>that thing is overwhelming with all its popups, hovers, sidebars etc.
I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.
I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..
- [deleted]
If you struggle with VS Code you must struggle with everything.
As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config.
Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?
I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity.
More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe.
My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.
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.
> Besides the functional approach
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.
I wasn't talking about programming.
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.
Hear hear. I poked around at almost all the packages on the top of that idemacs page. «minimap» stood out, and is such a brilliant name for its purpose. I enjoyed that discovery and the smirk it gave me today.
I would love to see a project that rebuilds the Emacs UI but keeps the underlying core to give it a modern facelift, some things in emacs blend together and are a pain for my eyes to figure out whats what. It would be nice if the UI was modernized but the core was left as-is. I'm reminded of some of my favorite editors that are niche being Lisp related ones, where if you held down ctrl it would show you shortcuts in the UI itself and what they lead to. I also always enjoyed Racket's import arrows and other small things that are visually amazingly impressive despite being so simple.
I'd argue the opposite. UI is ok, it can be configured to look timeless (not modern).
But the core with its single thread processing and constant hangs, requiring you to repeatedly hit C-g at least once a day, is first in line for "facelift".
You can make it look modern: get rid of all menus and bars so that there is nothing on screen except for the text you're editing. (e.g. search for minimal.el) It looks indistinguishable from any other modern editor / IDE in zen mode. Menus and bars are not necessary in these sorts of applications if you use then daily -- more efficient and powerful to use the command palette and key bindings.
Second this. The "ui" is perhaps useful when learning to use emacs, but every emacs user I've seen after a while has all of it disabled.
I've been using emacs with the "lucid" build since forever, as it's the leanest build that still gets a graphical window working on X11 and see none of the actual "toolkit".
I guess the pgtk build is required nowdays for native wayland support.
Yup, just the other day I was talking about it on subreddit, will repeat here verbatim:
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?
> nothing on screen except for the text you're editing
Just wanted to clarify, to me that's timeless. Modern would be having modern menus, pop-up configuration screen et al.. All the candy that appeals to a less experienced user, who worked with Idea, Sublime of VS code before.
There's a reason there's no beginner car, no beginner guitar, and no beginner drill. Those are either tools or toys. If all you want is to type some text, notepad (or the equivalent in other OS) is enough. But programmers do more with text. So they should know what tools provide those and how to use those tools. But then you'll find a lot of programmers barely go one level up from notepad with their tools.
I guess I'm not really sure that menus are modern. But anyway I hate the stubbornness over the vanilla emacs UI. The nonsense in the menus and the stupid pixelated pictures of scissors or whatever.
But I've never really got the idea of why emacs should appeal to less experienced users. I think that's misguided: the entire point of Emacs is that you write some emacs lisp. If you're not interested in writing any lisp, then you definitely shouldn't bother with emacs (I used emacs intensively for 20 years and am the author of Emacs packages). And if you're less experienced and looking for Idea/Sublime experience then at this point in your life there's a good chance you aren't interested in writing lisp.
Agree, those hangs are especially bad when programming with eglot or project management over a slow Tramp (remote) connection. An auto save hijacking your time for two seconds at random is flow breakingly frustrating. It's something that could perfectly well run in the background.
> requiring you to repeatedly hit C-g at least once a day
And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…
So we all agree we need Emacs 2.0™, rewriting both the UI and the guts? /j
I don't agree with everything in their approach, but Lem (https://github.com/lem-project/lem) is a modern editor that has the Emacs Nature.
Lem looks great and I wish we all could simply move there, I personally, am not married to a concrete implementation of Emacs, I just love the idea of an editor built atop a Lisp REPL; I don't think I ever could use a computer without having it.
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.
It's not exactly what you're looking for but you might be interested in Lem[0]. It's an emacs-style editor but written completely in Common Lisp on top of curses/SDL2. I haven't used it that much (same for Emacs itself, really), but it looks like a very solid foundation
Does look interesting, in the meantime I've been hooked on Zed which has users building support for missing Vim features, they claim their goal isn't to 100% emulate Vim functionality, but I would not be shocked if it just winds up having most if not everything most people like about Vim fully baked in.
You mean something like which-key? It existed for a long time as an external package and was added to main emacs recently. https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...
Alternatively beside which-key, hydras exist which are very nice for certain contexts (dired in the particular case for me) and provide a nice shortcut interface whenever activated. Demo at [0].
As far as I know, which-key only helps with key sequences. If you press C-c in Org-mode it will show you keys like C-c C-e, but if you hold Ctrl down it won’t show you C-RET for example.
Emacs can't do that for historic reasons. It just can't distinguish between keypress and keyup events. It receives input events from the terminal/OS. Terminals are text-oriented: They evolved to transmit characters, not hardware events.
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.
A good shortcut is "C-h m" which shows the help for the major mode (and current active minor modes). It will also shows all the bindings that those modes define.
If you want all keybindings, C-h b typically helps, and you can search within the single buffer it returns. Every key in Emacs is bound to something, but a plain modifier key event like Ctrl will not be sent from a terminal to any command that runs inside it, eg Emacs, only the modified key. (There exist modifications/extensions of this protocol, eg kitty, but most combinations wouldnt see these events.)
Sure, I know about C-h b and C-h m and find those useful. But I think what the GP post describes is more contextual: A way to not display every keybinding, but only those directly accessible by pressing the currently held modifier combo followed by one key (so holding Ctrl+Meta for more than a couple of seconds might remind you of all structural editing commands for example).
This is indeed not possible in a classical terminal emulator (don’t know if kkp for example has extensions for it). But most GUI apps can detect individual modifiers being pressed and released, even as separate events. Some editors like VSCode can also bind modifier taps to actions using this ability. In Emacs however this is AFAIK not possible even in the GUI, because of how keybindings are handled deep down.
The UI pattern described by the GP does exist in some other apps and platforms. For example, if you connect an external keyboard to an iPad, holding down the Cmd modifier for a couple of seconds will show you a popup which-key-like overview of all Cmd+key keybindings.
Agreed. I keep almost all things same between terminal and graphical UI, so I would never use it, but I can see the appeal of having the ability for handling keyboard events differently than character inputs in some cases in the GUI.
I would actually change as little as possible.
The current UI has it quirks, but has the great advantage that it looks the same irrespective of whether you're in an graphical environment (Xorg/Wayland/Windows/MacOS) on in a terminal (either local or remote via ssh).
I *love* that treemacs looks pretty much the same everywhere.
It doesn’t really look the same by default.
Most new users end up disabling the toolbar, menu bar, scroll bars, etc. and only then does it look the same in the terminal. Even then, many themes and packages frivolously change font sizes or switch to non-monospace fonts in some GUI contexts, so for users that like the uniformity of the interface you need to do extra work to disable these features.
(I personally like the terminal aesthetic, and configure the GUI to look like a terminal. That basically required advising load-theme to loop over all faces and disable font properties I don’t like after each theme change…)
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.
Similar story here. I used vscode for about 3 months for all my editing needs without even having Emacs installed, but returned to Emacs because of how hard it was to learn how to modify vscode (I'm not a web dev) compared to modifying Emacs and because of a vague impression that vscode is slower in responding to my inputs.
It's definitely slower when doing any intensive background activities that Emacs would normally offload. But I've found VSCode has features readily available as one-click installs that are very difficult and convoluted to setup in Emacs. For some of those you end up either settling for less-ideal tools in Emacs, or because you're not an expert in the specifics of the tool being integrated, you end up with a much less optimized integration. And in either case you can actually end up with a net-worse performance in Emacs, even though the VSCode core is in a far less performant language than Emacs.
> It's definitely slower when doing any intensive background activities that Emacs would normally offload.
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 actually agree with that. I should have added a qualifier to my previous comment (grandparent), namely, I use Emacs mainly for things other than programming, and if I ever start programming full-time in a language other than Lisp, then, yeah, (for the reasons you give) I'd probably use vscode instead of Emacs to do that.
I use Emacs for managing files (with Dired) running shell commands, bookkeeping, keeping notes and chatting with LLM services.
I was always bummed OniVim v2 didn't take off.
It was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim .
neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
From a quick glance, I can't understand the target audience.
Vim users would be annoyed by bizarre input lag of an electron application and perhaps by EULA. VS code users don't really care about Vim...
>of an electron application
It isn't an Electron application*, that's why GP said native. The EULA part though was probably a block to adoption.
*It uses Revery, a, made by OniVim's devs, cross-platform GUI framework (similar to Flutter but build on Reason/OCaml).
Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing). Thanks for the clarification.
The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
Should've probably mentioned it before but it actually used a dual-license model by having an MIT version that lagged behind upstream for 18 months (could be found in oni2-mit repo). During last month when development stopped it was fully re-licensed under MIT (hence oni2-mit repo no longer exists).
> VS code users don't really care about Vim
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.
Long-time (25+ years) Emacs user. The first thing I do on a new installation is turn off the GUI features (like, menus and toolbars) - no-one I know who uses Emacs uses the mouse.
VSCode users, especially new ones, do. The best property of Emacs is that you can modify the lisp machine to do whatever you want.
If you use an editor or IDE at work for a year, you might work with it for a thousand hours that first year alone. But a noisy GUI like VSCode's is optimized for just that first 30 minutes of playing around.
For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
> the lisp machine
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
- [deleted]
- [deleted]
Another long time (15+ years) Emacs user here. I similarly use it completely keyboard driven. I have seen someone use it with the mouse, though. My PhD supervisor used completely stock Emacs to do LaTeX and actually used all the menus to do stuff. Quite eye opening for me.
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.
As a 15+ years emacs user the only item on my wishlist is client-server remote editing mode similar to that of vs code. Then I can go back to using emacs on cloud VMs. Does anyone know a solution to this that works as good as VS Code even when your latency is high? Hopefully, I will be pissed off with all the weird configuration flags of VS Code enough to write one myself ;-) To be fair its python integration is quite good at least for the usual stuff.
Two approaches might work here:
1) Run Emacs on your local machine and use Tramp to edit the remote files 2) Run Emacs on the remote machine with the files you're editing. This likely means running in the terminal itself (emacs -nw or requivalently emacs -t).
This would have been great when I was learning Lisp in school! I tried emacs but due to joint issues the keybinds were painful to use, so I gave up and did the course in vim+SBCL's REPL instead.
It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense.
I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.
I use kmonad to make Space act as Control when held, and it's absolutely life-changing - not just in Emacs, but in all applications.
This is my configuration -
https://codeberg.org/contrapunctus/dotfiles/src/branch/produ...
And here's my blog post about it -
https://contrapunctus.codeberg.page/blog/keyboard-machinatio...
wait foot pedals ?
Or an accordion! https://x.com/ykarikos/status/1038145486618861573
Which joint issues? Have you tried evil mode?
> Which joint issues?
Pretty sure it's rheumatoid arthritis.
> Have you tried evil mode?
This was like fifteen years ago and I just went back to my working Vim setup I was already using for all my other classes.
Sorry to hear that. I have a family history of that as well. I think I'm starting to show signs of it.
Vim forever I guess. Im typing on a full split with cherry reds (very soft). What are you on?
Started using an Ergodox EZ with a custom map after I shattered one of my wrists in a vehicle crash, have stuck with it since.
- [deleted]
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.
i still use emacs everyday, with the native UI. but i love the idea of this project. Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons.
> Personaly i never get used to the UI of VSCode. seems so hard to understand because in emacs you deal with functions not UI buttons.
I prefer both Vim and Emacs over VSCode, but I teach intro programming at a university and use VSCode in the lectures.
VSCode is actually quite decent if you use it as a keyboard-driven thing with a distraction-free interface. By the former, I mean that Cmd-Shift-P does the same as Emacs’ M-x, and from the keybinding hints you quickly learn any recurring useful bindings (or can change them under Cmd-K Cmd-S when they feel bad). By the latter, I mean that nearly every UI element can be disabled (activity bar, tab bar, status bar, scroll bar, most buttons, indent guides, gutters, etc.) and if you spend 30min disabling the fluff it looks as minimal as Emacs. You don’t really need the UI elements if you learn Cmd-Shift-P and basic keybindings, which as an Emacs user you’ll pick up in a week.
Not trying to sell VSCode here, as I said I don’t prefer it myself. I really tried to switch some times, but I don’t like the Microsoft monoculture nor the importance of proprietary plugins (like remote development and pylance), and an Electron app usually has some weirdness when it comes to font rendering, UI bugs, etc. compared to native or terminal apps.
But if you have to use it, it’s actually not bad if you approach it in the same way you’d approach Emacs: Call functions with Cmd-Shift-P (can rebind to M-x if you want), and invoke more common functions via keybindings instead of UI elements.
> Cmd-Shift-P does the same as Emacs’ M-x
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.
well, that explains a lot. i guess its me not spending time to learn the basics of VSCode but got lost in the interface. seems a quite elegant design.
Until Emacs resolves the performance issues on Windows, all those custom distributions are questionable for me.
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.
Love to see this. I lost steam working my way through SICP a couple of years ago because I spent so much time trying to figure out Emacs instead of writing Scheme
This is an interesting project and the picture can certainly fool you for a moment.
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.
Does the fixed window layout really work with emacs though? In the past when trying this type of setup, I'd end up in the treemacs side panel showing a code buffer instead of the file viewer that is supposed to be there.
- [deleted]
Next up, how to make your Ferrari into a Fiero clone.
Seriously, though, this seems kind of counterproductive. The power of Org mode and some of the other tools in Emacs comes from being integrated into the rest of Emacs and the synergies from Emacs idioms and concepts working everywhere in Emacs.
Just my opinion, but the time spent learning this front end would be better spent just learning the Emacs UI. It's really not that difficult, and pretending you can't learn it just makes it more difficult in the long run.
It's more like how to put a modern day car dash over an F16 fighter jet. One has modern expectations and standards everyone is already familiar with but far less power and features, while the other existed before usability was even an idea but has more power and features than even most experts can handle. And in this case (and analogy), you can always slowly remove parts of the interface that hide the more powerful features.
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.
> It's more like how to put a modern day car dash over an F16 fighter jet.
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?
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?
As someone who doesn't use emacs how do i install this?
edit: i'm on windows
What I miss from vscode is the remote functionality, can you do it with emacs? For neovim there is distant.nvim, but idk if it is mature enough and configuration seems a bit annoying...
Emacs already does that with TRAMP via SSH -- You just open a file like /ssh:user@server:/etc/hosts the main downside is if your connection is laggy Emacs will lock up momentarily. There is an ongoing effort to improve the multithreaded-ness and async-ness of Emacs to make it nicer
I use TRAMP to edit code loaded on robots occasionally. One advantage compared to VSCode is that it doesn't require the installation of anything onto the computer you're connecting to, since it uses the usual linux tools to work. But it can freeze up once in a while.
- [deleted]
What kind of remote functionality? Lately, somebody mentioned https://code.visualstudio.com/docs/remote/tunnels
I believe the analogous thing in emacs is called TRAMP. I have no idea if it's good, as I never edit files remotely, but it exists.
Not at the same level. TRAMP is way behind feature-wise.
You mean like the way VSCode does by installing a whole mini version of itself on the remote computer?
Well, I guess? Using TRAMP with large projects is not a pleasant experience. It works great for one-off files and remote bookmarks etc, but for working with large projects you're better off mosh/ssh-ing into the server and using Emacs there. With things like term-keys [1] you can use all the keys there as well. Basically only missing out on images and variable fonts, both of which are none issues for me at least when programming.
- [deleted]
C-x, C-c, C-w, C-s, C-k, C-g, C-] - goodness me, somebody absolutely does not give a shit what anybody thinks. I would never use this, but, somehow, I still love it.
I dare the author to rebind M-x as well.
In fairness, Emacs has long had cua-mode for rebinding C-c, C-v, C-x, and C-z to copy, paste, cut, and undo, so at least those changes are not too radical.
Agree with you. Coming from sublime and always wanting to give emacs a fair try, I found ergoemacs [0] that wanted to expand the cua mode for beginners, but that was not enough for me. I wanted more, and now with IDEmacs it is almost like what I want. With emacs you can do pretty much anything, why not a full cua mode ?
It was pc mode and then cua mode
That screenshot is super pretty. Very impressive!
Thank you!
If you don’t use it that often, you might wanna try the Emacs plugin for VS Code instead.
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.
What on earth are you talking about?
Do you have any recommendations?
Yes the best one is https://marketplace.visualstudio.com/items?itemName=tuttieee...
I like to express my loyalty to the emperor of man and call this heresy
[dead]
I would really like to see this kind of work be done upstream. Emacs still looks the same as it did decades ago despite other editors advancing and becoming more user friendly.
Switching the default experience away from what people have grown used to over decades seems incredibly rude (despite what commercial software has normalized).
The magic of emacs is infinite customizability. And it's quite easy for users to find and start with emacs "distributions" or "starter packs". So that's probably the best route forward.
Potential improvements:
1 Base emacs continues to make it easier to try out a bunch of configurations and switch between them, obviating solutions like chemacs
2 There's a web repository of a a variety of starter packs with screenshots and reviews and installation instructions, to help beginners find everything in one place.
3 ...
Could be done with a flag tbh. One version to opt in. Next version it’s opt out.
> 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"?
Emacs is probably the most user-friendly editor. Its just not very beginner-friendly.
The problem is that you need to spend 20 years to get out of the "beginner" zone.
The curse as a power user is that you want to know how it works. I let that feeling go with emacs. I've been happily using it since. My first gateway and killer use case was magit. Life with git will never be the same.
I’m 25 years in and still firmly in the beginner zone
There are no "Emacs experts". Bedrock of Emacs is Lisp. Lisp is the essence of computation itself. It's both simple to understand (5 basic special forms) and impossible to master at the same time - you can construct entire universes with those 5 basic building blocks - quote, if, lambda, let, and set. If someone finds something cannot be achieved in Emacs they either are wrong, or wrong at the point in time - theoretically, anything can be done in Emacs, it's just a matter of time. So, technically, it's impossible to capture all possible features of Emacs, the totality is infinite.
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"
> Emacs still looks the same as it did decades ago
That’s a good thing. I don’t want to change my habits every time a designer of whatever product I use decides that he deserves a raise and breaks my workflow in some subtle way.
Please, no. Emacs could use some interface/toolkit update, I don't deny that. And I like IDE features. I use tree-sitter, LSPs, copilot.el, copilot-chat.el, and others all day, every day.
But don't force me to turn off treemacs, and minimap like I have to do in VSCode all the time just because some useless, space-wasting eye-candy is trendy.
I didn't downvote you, but you have a misconception.
There's no such thing as an Emacs "look". Its appearance, UI and UX, are wildly different depending on how the user wants it to look and behave. Considering that it is a very configurable system that happens to expose building blocks for a text editor, every Emacs installation is thus different from another.
We could say that the Emacs GUI toolkit and perhaps its internals are dated by modern standards, but even those would be personal preferences. Being single-threaded is arguably holding it back in some aspects, though that isn't a major limitation for most use cases.
My comment is discussing the defaults. Most users will use the defaults and not customize their editor, especially if they are just using it for the first time. The defaults are important.
The single threaded issue is a problem, but one that can be somewhat worked around. I consider emac's bad deals an existential issue that significantly hurts adoption.
> Most users will use the defaults and not customize their editor
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.
I'm afraid that many people consider "looking the same as decades ago" a feature...
It is, the default UI is stable and can be changed somewhat easily.
A huge portion of the emacs community seems resistant to any UI improvement. I think it's a counterculture thing.
It can hardly be called resistance to improvement, when everyone do improve it - just in their own ways. The default isn't some fashion statement, some aesthete that's objectively good (though I am sure some people do subjectively like it). But it's meant to be sort of a least presumptuous blank state that everyone can radically overhaul. So arguably it's an encouragement for improvement just like everything else in Emacs, which focuses on making the tools for improvement easier.
It's just that "improvement" as a matter of public consensus that everyone can agree on to elect the next blank slate has been to impossible to settle on. But the counterculture here broadly might be extreme reluctance to inconvenience even a minority of existing users, in pursuit of market share/growth.
There is no better UI for text editing that I have ever come across. I'm not sure why so many people are resistant to the idea that emacs has the correct answer to most UI issues. More programs would stand to take lessons from emacs. Emacs is, in its own right, a very successful piece of software. When eclipse was a thing everyone was saying how great it was vs emacs. But eclipse is gone (I think?) and emacs is still GOATed.
There's a particular kind of hubris from non emacs users (especially those who swear by new ides), that us losers are somehow deprived. We are not and don't need your advice. Nothing to do with counterculture. I tried many editors before I became obsessed with emacs.
>But eclipse is gone (I think?) and emacs is still GOATed.
The 2024 stack overflow developer survey [0] puts Eclipse at over double Emac's market share. If Eclipse is gone, then Emacs is double gone. Emacs struggles to attract and retain new users. This advice is not calling existing Emacs users deprived. It's rooted from the bad defaults giving new users a bad impression of Emac's viability because the default is so bad. If emacs built out proper telemtry they could actually track how the defaults they provide affect the new user experience in order for them to optimize it and figure out what users are looking for.
> If emacs built out proper telemtry they could actually track how the defaults they provide affect the new user experience in order for them to optimize it and figure out what users are looking for.
I can't tell if this is an attempt at humor or something people actually believe
> If emacs built out proper telemtry they could actually track
Good God, NEIN!
It's because a lot of us resist the implicit argument that UI changes are automatically improvement when in fact it's just as often regression.
Yep. Look at IntelliJ. It just copied VsCode when it already had a great UI where things were easy to find and consistent. Now it’s got meaningless icons and hides important stuff by default, making it modern but far worse than before. Thank goodness emacs is not trying to chase the latest and stupidest.
Nonsense. Many emacs users spend their whole lives inside of it so they're quite sensitive to what is actually an improvement and what is not. The arrival of the various modern completion packages -- vertico, orderless, consult, etc. have been welcomed ... but note that these are all add-on packages. Likewise, all of the "improvements" provided by the OP are a matter of loading and configuring packages.
People who aren't regular emacs users tend not to understand it and are not reliable reporters about the editor or its community.
It’s not counterculture. It’s understanding of what’s important. Functionality, discoverability and extendability over opinionated UI/UX that nobody asked for.
Well people will vote with their mouse clicks, and they have, < 1% of devs use Emacs vs VS Code which is probably 20-30x.
I mean, okay? That’s their choice. Not everything is a competition.
For me, VSCode implements everything that I've always expected from Emacs/Vim.
I've spent years to configure emacs/vim to be a good programming editor. Years, multiple configurations, vanilla configs, space/doom emacs configs, multiple predefined configs for vim/neovim. Something always was broken, something was missing, something was non-optimal just below the tolerance line. Missing features, discontinued packages, initialization errors, bad versions, "known issues", LSPs not starting, packages replaced by some newer shinier package with different usage, cryptic setups that are wrapped in "convenience layers" that obscure details, making it completely incomprehensible.
Then VSCode came and it had everything. Remote development is trivial through ssh. Completion simply works without any setups. Massive number of languages supported. It's a mess inside, but the UX is more stable and more consistent than anything I've ever seen in emacs/vim. Sometimes something breaks, but I can restart the window backend without closing the app easily.
This is really telling. Despite dedicating years to configure an "infinitely configurable" system, I wasn't able to achieve anything stable. I've given up and i just use VSCode daily. This way, I have more than I ever had with emacs/vim.
The only thing I have from vim that's left is the keyboard layout. For this, I'm thankful to Vim, but the editor itself for me is just for editing config files. I don't even have Emacs installed anymore.
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.
The data shows VS Code is used by double digit % of developers, whereas Emacs is less than 1%, I think that qualifies for most.
That's not the point - McDonald's has 40000 joints - the most popular restaurant in the world. Still doesn't make it the best food option.
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've installed emacs now on ArchLinux Wayland system and its window refuses to resize (on purely default settings), and freezes the contents until I move it. Very refreshing indeed.
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've installed emacs now on
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.
Yes, I'm always having "special" problems. It's probably due to the fact that I jump around platforms a lot between Linux, macOS and Windows, mixed GUI and ssh.
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.
Yeah, I admit, fair complaints. Emacs can be tricky to render things exactly how you like - I use it on Mac, Linux, GUI and terminal and do have different semantics for each.
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.
- [deleted]
> one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work
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.
> In Emacs I can reuse functions of one package in another
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)
I'd prefer Emacs Lisp had Common Lisp style packages (with namespaces and exports), but in practice it's not much of a problem. Emacs is intended to be programmed by its users, so you don't have "private APIs" in the same way proprietary systems do. Actually internal functions and variables are usually marked with naming conventions these days.
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.
> You say like it's some kind of feature
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.
> For me, VSCode implements everything that I've always expected from Emacs/Vim.
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.
OKAY.
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)
> I hope you're happy
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...