I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.
I use emacs daily (with vim keybindings of course), but I completely understand why vscode is so popular. It's extremely easy to get started with, has features galore, and sane defaults. Emacs takes much more effort to get productive with, although this is improving with each release.
In general, I find that good defaults are rather undervalued and downplayed in the FOSS world.
Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.
Defaults really shouldn't change. Each time I upgrade my OS, I get a new version of vim, and have to add more
Until about 2022 this was fine, then they introduced things like shifting the scrolling window, breaking mouse support, I think changing search to highlight text etc.
That's fine, but that means everytime I run it on any machine I have to now deploy a vimrc to fix it.
(I think I noticed the regressions starting in vim 8)
You speak from my heart. How many years did it take Debian to activate syntax highlighting for nano? Is the bash history still very short? So many low hanging fruits.
Same with no screenshots on github projects (For GUI projects)
The terribleness of emacs defaults is over done. I still use p n postfix key combinations to go to previous and next and f b postfix for forwards and backwards, it's just what you get used to, C-w to c-y to kill and yank are also fine and it's not that much to ask the user to change things if they don't like them.
Not to mention all the emacs distros that now exist for people who do want a very different configuration. I maintain that default emacs is fine though and if the user wishes to get really in tune with emacs, emacs is one of the most pleasant environments to learn thanks to help pages and how flexible elisp is to evaluate and poke and prod around with and how easy it is to debug.
I think most modern editors will try and introduce mutlithreading and other features that emacs did not do due to it's age and is better for it as it means elisp code just works together and less worry about synchronization and other bits that would exist with more modern ways of approaching the problem (not saying the approach it's self is bad, but for an editor emacs and the decisions around it are largely very good and surprisingly so)
Exactly, this my point. If you want to make a great editor, the proper thing to do is start from a good base. Start from emacs and make something like doom emacs or spacemacs, etc. Or start from vim or whatever. Text editing at speed is a solved problem. It's just 'not-invented-here' syndrome. I admit that base emacs may not be everyone's cup of tea... that's fine. Just download one of the many pre-configurations.
Because very few people actually care about the things that emacs has to offer.
Tools like VS Code do the job well enough for the majority of people, with just enough configurability and much greater ease-of-use.
Emacs has a similar problem to Lisp: Infinite configurability and expandability (plus the lack of a "blessed set" standard that people actually like enough to use out-of-the-box) means that everyone's environment and tooling ends up becoming incompatible with each other.
It's just easy to install on Windows. Base emacs does exactly what you want it to do. And my emacs v vscode comparison was specifically because of infinite configurability and expandability. VSCode has the same thing with its myriad javascript extensions.
Because Emacs is not a text editor, it's rather a text orchestrator. And Emacs Lisp is specifically text-oriented, unlike most other Lisps that are data-oriented. It fits incredibly well for LLM-flows. I'm surprised how it remains enormously flexible even though my workflows change every day. The way how I used LLMs last year vastly differs from a few months ago and totally unlike of today, yet bending Emacs never hits the ceiling.
If I had a way to send a message to my younger self, it would've been: "drop whatever you're doing, start grokking Linux, learn Emacs, and maybe Vim...". I never had any regrets about my career choices of the past, yet "fuck Microsoft!" I spent years digging dotnet, sqlserver, etc. I invested heavily into WPF and Silverlight, I believed their propaganda. I don't feel even a half-pint of value from the experiences I gained, it all turned out to be useless crap - none of it squeezed even a drop for becoming a hacker out of me. Learning FP, Lisp and Emacs brought me closer to that goal.
work amazingly well, almost perfect. I have not see anything come close to what you can do with emacs and the easy to which ai can be integrated and slotted into emacs.
> Because very few people actually care about the things that emacs has to offer.
Most people are simply unaware of "what Emacs has to offer". Even long-time users sometimes don't realize what Emacs actually is. They treat it just like any other text editor. Well, Emacs is not an ordinary text editor in the traditional sense. It is rather a text orchestrator - you can manage any text-related tasks in its computational vicinity - text that appears in any local app you see on your screen or lives on a remote machine.
> everyone's environment and tooling ends up becoming incompatible with each other.
It was never a problem because Emacs packages are not extensions - they are recipe books. Yes, you can often use them as ready-to-play "products", but eventually you'd have to look under the hood. Yes, it makes it difficult to maintain transferable help because an answer written for someone else's setup may not apply to yours, but that's by design - the complete absence of interface boundaries is the point. Nobody calls out a "compatibility crisis" on shell prompts.
> Tools like VS Code do the job
Yes, VSCode is "easy" - you can install it and it's either useful in ten seconds or you quickly find what you hate about it. Emacs is not "easy", it is "simple", it pays off only after months of investment, and the ROI from it can be immeasurably bigger in ways that you might have not realized before it.
You can inspect a hammer before buying. You cannot inspect Emacs, because its value isn't in the artifact, it's in workflows one simply cannot evaluate with their pre-emacs values. It wouldn't occur to you to want a fix for something that doesn't register as a problem.
Software should never be restrictive but egalitarian and accommodating. So often do I feel like rolling my eyes whenever I pair with my colleagues - I'd do something trivial, like fetching a list of PRs related to a specific ticket when the cursor is on it. They'd be like "whoa, that's cool", and then never do anything about it - they stick to their "learned helplessness" paradigm - copy the ticket number, switch to browser, navigate to Jira, pass through SSO, find the phone to confirm it, push the button on the phone, paste the ticket number, find the linked PRs, etc. And our other teammate watching all that may say something like: "I think if you do it directly on GitHub, it'd be faster"... And here I am - pressing a key, voila - the list. Why the heck they don't do anything about it, I just don't get it. Trained engineers, they spend years dealing with cranky software, why in the world are they unwilling to do anything about these seemingly small annoyances? Why do so many programmers treat software as if it's magic? And I think I know the answer: because the software you use shapes your affordances. If there's no downloadable "get-me-list-of-prs-for-a-jira-ticket" extension and there's no simple way to build it, it would never occur to me to be annoyed. In Emacs, I can write a picker in a scratch buffer by hand and it would take me minutes.
They jump to such tools, because they are not that invested in making and having the optimal tool for their job, and don't want to spend time setting things up. Especially, not in their own time, if they even do any projects in their own time at all. Lots and lots of people in IT are not that dedicated or passionate about the work.
Also another reason for having a single tool for a whole team: I can go to my coworkers desk for pair programming and have the same setup. I know the shortcuts, everyone has the same "run configurations" (start app, remote debug etc.), starting gradle tasks from UI, git comment style.
Counterpoint: when you go to a coworker’s desk you shouldn’t be touching the keyboard or the mouse otherwise they are just watching you do their work. You should have them come to your desk if you want to be the one running the show. Everyone can have their own environment and they translate what you say to their own methods and it helps them learn.
If you work on web tech (and who doesn’t these days?) VS Code has the advantage of using the same tech stack you’re already familiar with. If you need to debug a problem, just open devtools. If you want to run a performance profile, do the same. If you want to fix a bug in the extension you’re using, just open a PR and fix it.
It is a very flexible system and still quite fast and easy to configure. I’ve been trying Zed and WebStorm looking for better alternatives, but it turns out they have their own problems. Zed isn’t nearly as configurable, WebStorm’s config system is an absolute nightmare (xml for days - and constantly changing, mingling actual config with transient state).
People complain that VS Code is slow; perhaps on some metrics and perhaps it is slower than a much less featured system like sublime. But I don’t think it is meaningfully slower in practice than Zed, and they make a lot of compromises to get that edge.
using a js engine is anything other then a selling point IMO. I don't hate javascript but sure hate the ecosystem and the tendencies of js or ts developers today. I would not want that approach in my editor at all. elisp and js actually share some things in common and their is no reason a developer would struggle to learn elisp and once they do they will probably like it and the very light weight emacs rendering system, everything is text is a fantastic paradigm for a text editor or an IDE. web technologies like Html/js are actually too complex and can do things you don't actually want your editor to do when rendering bits of interface. I want text and nothing else and I want to hook into text renders easily and without having to worry about timings asyncs and other features of the modern web interface. It's that emacs is simpler and understands that one does not want everything a modern browser can do.
> But I don’t think it is meaningfully slower in practice
It's all relative and perceptional, no? It really irks me that when you grab a freshly installed VSCode and install just a single extension for vim-support, there comes a palpable typing latency. Just like that. I currently use about 300 packages in Emacs. I can't ever imagine even attempting half of this number of extensions in VSCode. Would it even start?
VSCode's problem isn't that it's slow, it's that it's bloated. It takes a bit over 1GB memory (in my testing) to open the same files that Sublime can do in just 200-300 MB. In my book, it is simply not acceptable to waste my memory like that.
I just tried opening a 730 MB file in both and VSCode's usage was just around 2 GB while Sublime's usage (fresh install) was over 3 GB. This is even with my normal VSCode extensions enabled (91 currently).
I’m trying to phrase this to not be “that guy” but have you used Code on large code bases? Vscode on my m2 Mac routinely crashed when doing file search. That is why I switched to zed.
The monorepo I work in has 2-5x as large (depending on how you count) and I don’t see crashes or major performance issues. Even when bloated with plugins (testing, GitHub PRs, formatters, copilot, vim emulation, codelens turned on, etc). And I have an older presumably slower Mac.
Text manipulation isn't just about creating content - it's also about how you consume and interact with it. Just because text appears in a different app, with a different format, or different fonts and colors doesn't mean your editor shouldn't be easily grab it.
While typing text in my editor, I can:
- Read the list of urls on a webpage in my browser
- Check if any links lead to HN discussions
- Search for text on a page, switch tabs, or list urls of open tabs
- Search across all open tabs for a pattern
- Control YT vids - rewind, change speed, pause, mute, transcript, etc. - handy when watching and taking notes.
I can capture any area of my screen and have the text OCR'd directly into a buffer. Even grabbing a code snippet from a Slack thread only takes a single keystroke. None of these apps have "compatibility layer" or RPCs or designed to talk-to-one-another. The only shared property they have is text.
Vendors are designed to keep your text a hostage, that's why whatever text-editing system you choose, it should have means for reaching out and extracting text from anything you want. And that is not a "solved problem", not for everyone.
That’s easy. Because if they accept that emacs is good enough, they have to then accept that probably whatever thing they’re building is almost certainly worthless.
26 different browsers all based on Chromium, 127 different “observability platforms” etc.
So so much redundant rehashed stuff. We can’t accept that though, THIS TIME it’s going to be great and amazing and we’ll get a huge investment and sold to a huge company for millions.
I’m not suggesting that it hasn’t been a huge leap in computing and software in the last 40 years.
But we need to have faith in new being better to keep going. That’s why the new hotness is always so popular.
The interface of text editors has not substantially changed since the time of interactive editors like VIM and emacs. Line editing is an entirely different paradigm. If you are actually going to change the paradigm with which we edit text away from the grid of characters and cursor approach, then by all means, go ahead and write your own. But if you're just making yet another text input pane, then vim and emacs have that problem solved.
You are talking about vim AND emacs but they have completely different approaches, I wouldn't call that solved?
If instead of general text editing we talk about specialized editors (for example emacs for lisp or powerful IDES) they're gonna beat vim or emacs any day (vim is never going to be better than emacs at writing lisp).
Whichever you want. There's a million text editors today because people have different approaches. I'm not criticizing having different approaches. I'm criticizing people who start writing their own text editor instead of just building off of established platforms.
You're just avoding the same question - why not build off the established platforM - which one, though? Why not VSCode, which is also an established platform?
I always wanted to learn emacs, but I never do, because while I don't know it using it doesn't pay off. I did the tutorial at some point (I mean great that it exists) and now I can move around and close the editor, but that's the same I can do in nano, so I keep using nano.
That’s how you start with emacs but as you need to do more complex actions emacs will be able to support you so your skills will grow if you keep using it.
