Posted by signa11 16 hours ago
I used to be on neovim, and that ecosystem compared to emacs feels like this image: https://i.imgflip.com/2pg2s7.jpg
Some of it is the maintainer shielding us from the breaking changes, but I also think the ecosystem is more slow moving than other editors which helps. The editor is older than most devs after all.
You're probably thinking of kill ring, which I always thought was a neat term.
Nothing's wrong with it. It's just incomparable categorically. Just like you can't really equate a photo-editor and the web-browser. Sure, there's a way to do photo editing in the browser, still will be weird to compare them.
> Neovim has been much better
In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
> I just want a good text editor
Is that implying Emacs doesn't have "a good one"? You probably just have not discovered some mind-blowing features of the editor. It is hands down the best-known machine ever designed to deal with plain text, nothing even comes close. Indirect buffers alone are such a brilliant idea, I have zero clue how people ever exposed to that power would willingly abandon it. I get it though, building a text-manipulating theater orchestrated by Lisp is not for everyone. Unfortunately, most newcomers get attracted to Emacs hearing "how powerful an editor it is", without ever learning what exactly makes it as such.
Unless this is specifically what you want to do with Neovim, in which case you'll probably just use Emacs anyway, Neovim's inability to do this is probably not a strike against it. As royal__ says (https://news.ycombinator.com/item?id=48537120), they are just interested in a good text editor, not in raw computational power.
A common reason for breakage is/was:
- Neovim changes some API (deprecating, ...).
- User upgrades Neovim and theres some incompability, OR user upgrade plugin and that plugin assumes a much newer version of Neovim. (I've often seen Neovim plugins "mandate" either the latest stable Neovim or even HEAD).
1. Neovim has been including some popular plugins (or at least their functionality domain) in the past few years. This obviates the need for plugin-for-$THING, and reduces breakage.
2. ISTM that the pace of (new) plugin development in the Neovim-sphere has slowed down.
I can remember removing vim-commentary (from tpope) a while ago because Neovim included something like it in the main distribution. Granted, that specific plugin never broke because it uses the stable viml API.
No such thing exist in neovim (or at least in times when I was using it), so that churn never ends. Also I find, that neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner - folke often takes time off and half the packages one uses stands still.
But in the end, while I like neovim, I also find that emacs ecosystem has better ideas - which-key, embark do not stop to amuse me (I will not comment on whether it is a good thing for a text editor). I also do not like lua and actively dislike the experience of debugging and configuring neovim with it (maybe less of an issue with LLM these days).
In my experience, running in a terminal absolutely adds a bunch of rendering/performance issues and all kind of surprising failures with hotkeys.
> No such thing exist in neovim
neovim has been doing that too. Plugin manager (vim.pack), treesitter stuff, LSP management, completion, comments, etc.
> which-key
neovim also has this.
> neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner
folke has nice stuff, but I find a lot of it is largely unnecessary and bloated. The only thing I use is his which-key, and there are alternatives, such as mini.clue.
I used it more than I use emacs, but I agree with the assessment of doom emacs vs neovim.
I hope with these new built in alternatives that will change.
It’s a bit sad Neovim has stolen the thunder from the original work of Moolenaar & co. My guess is that neovim will splinter itself down the line further again once lua stops being attractive, while vim & Emacs will keep chugging along for another half century.
Neovim seems fairly reasonable. Using the LazyVim distribution of Neovim and it works quite well for my purposes.
Respect where it's due to folke, he's been pushing the neovim ecosystem forward incredibly fast. The bleeding edge just ain't everyone's style though.
Seems worth a look, simply because it’s from the magit author.
> The editor is older than most devs after all.
Well, being old does not automatically mean better. Peak human physical performance typically happens, with some exceptions (Justin Gatlin, if we ignore the use of enhancement drugs) in younger years; see Usain Bolt's fastest time achieved when he was young (23 years, in 2009). For mental tasks it is not so limited, but for physical peaks it is often in the younger years. For some software projects it also is the case that older age means more code, which in turn automatically mean smore bugs, all other things being equal. I am not necessarily questioning as to whether emacs has more bugs; my point is that the comparison/analogy does not work as means of quality assessment.
You just cannot compare software robustness to human lifespan. Does software need 3 years at the bare minimum to be self-sufficient? Does it become argumentative and crashes a lot after 13-14 years?
Do not underestimate wisdom as a cognitive skill, even if in today's world we tend to discredit it because of agism.
LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.
With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.
With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.
Let's reword this a bit: "I wish Lisp use was more popular with LLMs...", because using Lisp REPL with AI is such a "life hack", I don't get why more people don't do that. When you give AI a "true Lisp REPL" it works wondrously - it stops randomly guessing and starts empirically understanding the problem and the code - saving time, tokens, your mental energy. And with Emacs' text manipulating machinery on top of that, things can get seriously interesting.
C-u 0 M-x asi-optimize-everything
And compare-windows looks really handy. I was about to write a note in my init file to my future self telling me to start using that, but then I saw there is already a note there from my past self, telling me about compare-windows.
scroll-all-mode seems useful, but it seems to only handle keyboard scrolling, not mouse-wheel?
Use `C-h k` and then middle click on the ruler-mode’s header to find out what command is bound to the middle mouse button, then bind that same command to a different mouse button:
(keymap-set ruler-mode-map "<header-line> <down-mouse-3>" #'ruler-mode-mouse-grab-any-column)For example: Just a few minutes ago, in a directory with lots of PDFs, I did:
- wdired to rename pdfs to a consistent convention. Did this with the awesome multiple-cursors package, then interactively spell-checked and corrected my renamed pdfs. All within writeable dired :-)
- delete several non-pdf files
- mark several possible duplicate files and dired-do-shell-command with sha512sum
- move several pdfs to another directory (split window and open target dir, mark files to move, one-button move using dired-dwim-target.
- mark several pdfs and open with reader app
Obviously that's all do-able with a shell or traditional file manager GUI, but dired was a total win here.
Multiply that win by a hundred times per week, and that's a quality of life enhancement.
DIRED on ITS is also similar enough to today’s DIRED.
More seriously, what I would like to do is ediff files (only the differences) in two directories (have the changed files together one line after the other)
or, ediff two arbitrary lists of files and have them show up in ediff.
I tried using it maybe a decade ago and back then it had a tendency to mess up window layouts and leave weird buffers around. I notice there's now a GitHub repository which has two spurts of work in its history that probably didn't exist when I last used it – have they improved its usability?
This reminds me of the fading but ever present power of institutionalism. For probably good reasons we accord higher respect to the Tonight Show than some rando podcaster. But at least in emacs's case, there really is no quality difference between a "batteries included" mode and one off the rack.
Emacs is a kitchen and emacs-packages are recipes - they come with the exact instructions (source code). If you try to cook fifty different meals all at once, your kitchen inevitably would be a mess. You need to know what you're trying to cook and how to work the recipes, and that comes with experience. No starter kit gives you a structure to un-mess your kitchen magically. Every sufficiently complex Emacs config is a system - a composite interweaving network of thousands of expressions, millions of code lines - it is the Space Shuttle equivalent; Neovim is like a simple twin-engine and VSCode is like a Cessna in comparison. Updates break your Emacs, I update things multiple times a week and rarely anything breaks (I consume over 350 packages); when things stop working - it doesn't usually take even a minute to figure out what's up. Yes, it does happen, but not as often as you painted it. On the other hand - when I need to get something done, there's no other tool in existence that can help me better.
Only once was there a noticeable breakage when a command like `git log` in the terminal would spit out all its output instead of displaying one screenful at a time. I'd expect someone following stable releases wouldn't experience any breakages.
I've been using emacs every day all day every time I'm front of a computer, since 1991. I need only one finger to count the pieces of software I've been using that long that have never crashed or broken on me in any way.
I have also run into compatibility issues when using older versions of Emacs with newer packages, and newer Emacs versions with older packages.
[1]: I totally did not build my blog on top of a bunch of these quirks. Every time one of them is fixed I'm reminded of the workflow xkcd. https://m.xkcd.com/1172/
But I agree that it is very stable and for me also doesn't break, even though I use use-package a lot and install many key packages. Maybe it is important to note, that I don't need everything there is out there and that I remove not well working packages quickly after trying them. From time to time I also look at my init file and get rid of no longer used stuff.
Recently I finally start to C-X M-x to do text scaling, the typing is hard even as near 2 decades user of Emacs.
That said, I'm the kind of person to invest time in my editor and I appreciate this post.
Emacs is not an editor. Emacs is not an IDE. Emacs is a platform to develop your own tooling. Text is the main interface Emacs offers.
I don't speak for the Emacs community, there isn't even such a thing except maybe semi related groups that share viewpoints, usage and interests. But on the whole, I don't think the "Emacs community" is looking for users or is looking to attract users. At least not users who are looking for "text editor experiences" that mimic or take inspiration from VS Code and the likes.
There was a "community" about a decade or two ago. On Freenode IRC, there were regulars who hung around in #emacs and it was quite nice. There were no corporate sponsors or random startups trying to hire from there so it was genuinely just a bunch of people who enjoyed using Emacs and were chatting about it. It's a part of the reason I got really hooked into it. I still use Org heavily for meeting minutes etc.
The "out of the box" experience could be better - but for emacs users. Those, who expect VS Code, should just install it and live happy.
What truly is a problem and extremely difficult to solve, is getting multi core and concurrency into Emacs properly. A truly concurrent lightweight thing would be so amazing to have and make package development probably much easier. No more worrying about accidentally blocking the UI and all that.
To get there would probably break many existing packages and would probably occupy all maintainers for 3 years or so, because Emacs comes from a time, where software was not designed to support that.
It’s like a pet. I love my dog, I’m happy to tell you about my dog, share pictures, etc. But in sharing, I’m not asking you to take _my_ dog. If you’re inspired to go find your own dog, train it, care for it, you can have a dog too!
But neither taking my dog nor the first-day experience of your own dog will replicate, and asking for a dog with a good OOTB experience IMO misses the point.
I'm not sure it does. Emacs has a healthy user base of people like you and I and appears to receive stable funding from the FSF. I don't see that changing any time soon. Emacs can be Emacs and be just fine the way it is.
I will keep suggesting new users should aim to get as close to vanilla as they have patience for, because that will teach them more about the powerful virtual machine running their text editor, and the ways it can be bent to do their bidding.
No, about ten underemployed or semi-retired graybeards on the emacs.devel mailing list burn most of their waking hours futzing with emacs. That's not an exaggeration. They receive no remuneration.
for emacs to gain mindshare, it needs to meet people where they are, not where emacs was 30 yrs ago.
of course, emacs does not work reliably in windows, so that is another issue
No, it's the same issue. In a Linux shell (say, bash or fish) ctrl-c is not "copy" but "terminate program". Most emacs editing keys (copy-paste, motion) work in the shell as they do in emacs, at least in fish and bash (and probably other places in Linux).
It made sense that interrupt in Emacs could get into a controlled state of receiving the next command. It's a little bit like the SAK (secure attention key) concept, as seen with Windows use of ctrl-alt-del.
Edit: Ironically, as a long-term emacs user, I don't really remember any commands that start with ctrl-c! For me, the most common sequences start with ctrl-X or meta-X. Or the prefix search commands ctrl-S and ctrl-R.