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.
Like you, I've been using emacs (gnu) for decades, and dired is my directory/file manipulation tool, for both linux and windows. I never see a desktop with files/folders or anything like that, it's dired for everything.
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.
it's bare but i'm surprised people would get confused by it, it kinda follows the usual shortcuts over bare unix util output: mark/select, delete, rename, compress, encrypt
then maybe you dislike the low-discoverability of shortcuts, i think someone added a transient layer (aka a visible shortcut summary with some state management for options)
I have an opposite argument - no other file manager ever worked for me and I tried and keep trying so many. And not because Dired "is so much better" or "far more capable", or "has better default keybindings", or due to my muscle memory or Stockholm syndrome, no. It's because I can always introspect every single feature of it, override any command, integrate things with any other packages.
I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?
Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.
It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.
Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.
I saw orgmode once and I really loved it. Used Doomed and spacemacs. But dear Lord, does everything break on updates and need fixing. I had to give up as I just don't think it's feasible for me to fix my emacs when I want to get some work done.
> does everything break on updates and need fixing
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.
My 2 cents (I hope I don't offend anyone, and of course Emacs community is amazing). I've been using Emacs full-time since ~2010 but I must admit it's been more like part-time along with VSCode since ~2024.
> This is largely a discoverability problem
In my experience it's not a discoverability problem at all. Not even a little bit. My problem with emacs batteries has always been stability between different combinations of packages. I know how to use dired, I know how to install elisp packages, I know how to write emacs lisp myself. The issue with emacs is that it's difficult to create large packages with "batteries" because any additional package added can bork some random, seemingly unrelated package. E.g. back in the day (maybe around ~2020s or a bit before?) I've been using Spacemacs without vim keybinding, and although batteries were included and I was happy, this issue I mentioned above was even bigger. Because I constantly had to deal with installing a package and discovering that it broke some unrelated LSP, programming, or autocomplete package. It gets quite a bit frustrating at some point. Since this LLM madness started, I never really installed anything LLM related to Emacs, and have been using other text editor for LLM related stuff, Emacs for everything else (especially if there is a strong Emacs package, e.g. agda2-mode is incredibly good, almost flawless!)
Again, just my humble two cents. Obvious Emacs is amazing, and in many ways it's still my go-to, I just think that the biggest issue for me has always been randomly broken packages. Maybe I'm a terrible elisp programmer, that's possible! But I've been using emacs everyday for decades, so idk...
All the other comments in this thread talk about emacs instability when that hasn't been the case for me. I'm on doom emacs, update once in a while, and everything mostly just works other than some color scheme weirdness I had to fix.
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.
20 or 25 years ago it almost never crashed. Now I might see a crash or freeze once a week or so. And slowdowns several times a day. Of course I'm running more modes now in a more customized environment. Hopefully this new version with more in it will improve the situation.
The biggest problem Emacs has will not be solved by blog posts like this. For most people the editor is a means to an end. They are invested in their end goal, not in hunting down blog posts telling them how to make better use of their tools. If Emacs wants wider adoption is needs a better out-of-the-box experience, which is something that distros like Doom Emacs and Spacemacs offer. That's the only way to make a dent: when people boot it up it has to have the good stuff right in their face. This also means ditching the "vanilla Emacs only" snobbery.
That said, I'm the kind of person to invest time in my editor and I appreciate this post.
Why does emacs have to be for everyone? Its attraction, to this user at least, is the lifelong process of adaptation and discovery that molds it to the user, and the user to it.
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.
TIL about ruler-mode; now I can delete my own half-assed implementation of the same.
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?
Cool blog post. Though I think the blog post would benefit from having a table of contents. Some things one might know about or not be interested in, but one has to scroll through them anyway.
Both Emacs and Neovim reward rtfm and working up from a vanilla configuration to your own custom one.
The distribution style packages for these editors make the user skip all that initial learning and discovery. It leads to people writing plugins and packages that simply replicate what was already possible. I have written plenty of elisp myself only to find out I was rewriting builtin functionality.
I'd also say that both editors are fully discoverable but you have to first learn how to use the various help available. Emacs is a bit ahead here with its help options, letting you search for functions, variables, info and man pages, apropos (fuzzy search) and more.
In short start vanilla and explore; this kind of blog really helps with that.
Half of the obscure features mentioned required the author's massaging to make useful to himself. The history of these "solutions looking for a problem" is common, some guy reveling in a rabbit hole of his own creation, the only difference being that guy was old enough to have a gnu.org email address whereas the rest of us publish our dabblings on github as third-party packages.
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.
Back when I was on usenet, it was a common joke that all real programmers used emacs - and at the time I was a vi guy. It took me so long to get the muscle memory to do what I needed in vi that I thought I'd never change. But sure enough, I'm a nerd, and just like when I tried to learn the Dvorak keyboard layout, I decided to spend two weeks learning emacs. Absolutely frustrating for a few days. But I've been on emacs ever since. Some years I didn't update my emacs config or install any updates at all. Some years, that's MOST of what I did.
No shade at all to VIM or any other community of evangelists who have taken the time to get all the power they can out of their toolset. What works for you works.
But between org-mode and the 70 other features that I've come to know and love (like projectile, flycheck, ivy, m-x butterfly, yasnippet, etc.), I'm never looking back. I will occasionally use another tool for a specific purpose, and sometimes those tools have features and niceness that is hard to beat, but most of what I do professionally is just plain typing and I'm way more productive in emacs than any other typing tool.
Pretty cool that after all these years I can see an article like this and learn a thing or two as well. Thanks OP!
32 comments
[ 2.8 ms ] story [ 50.6 ms ] threadMore 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.
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.
Aha! That's what's been missing in my life! Thank you.
then maybe you dislike the low-discoverability of shortcuts, i think someone added a transient layer (aka a visible shortcut summary with some state management for options)
I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?
Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.
It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.
Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.
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.
> This is largely a discoverability problem
In my experience it's not a discoverability problem at all. Not even a little bit. My problem with emacs batteries has always been stability between different combinations of packages. I know how to use dired, I know how to install elisp packages, I know how to write emacs lisp myself. The issue with emacs is that it's difficult to create large packages with "batteries" because any additional package added can bork some random, seemingly unrelated package. E.g. back in the day (maybe around ~2020s or a bit before?) I've been using Spacemacs without vim keybinding, and although batteries were included and I was happy, this issue I mentioned above was even bigger. Because I constantly had to deal with installing a package and discovering that it broke some unrelated LSP, programming, or autocomplete package. It gets quite a bit frustrating at some point. Since this LLM madness started, I never really installed anything LLM related to Emacs, and have been using other text editor for LLM related stuff, Emacs for everything else (especially if there is a strong Emacs package, e.g. agda2-mode is incredibly good, almost flawless!)
Again, just my humble two cents. Obvious Emacs is amazing, and in many ways it's still my go-to, I just think that the biggest issue for me has always been randomly broken packages. Maybe I'm a terrible elisp programmer, that's possible! But I've been using emacs everyday for decades, so idk...
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.
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.
https://www.youtube.com/watch?v=D1sXuHnf_lo
That said, I'm the kind of person to invest time in my editor and I appreciate this post.
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
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.
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?
The distribution style packages for these editors make the user skip all that initial learning and discovery. It leads to people writing plugins and packages that simply replicate what was already possible. I have written plenty of elisp myself only to find out I was rewriting builtin functionality.
I'd also say that both editors are fully discoverable but you have to first learn how to use the various help available. Emacs is a bit ahead here with its help options, letting you search for functions, variables, info and man pages, apropos (fuzzy search) and more.
In short start vanilla and explore; this kind of blog really helps with that.
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.
No shade at all to VIM or any other community of evangelists who have taken the time to get all the power they can out of their toolset. What works for you works.
But between org-mode and the 70 other features that I've come to know and love (like projectile, flycheck, ivy, m-x butterfly, yasnippet, etc.), I'm never looking back. I will occasionally use another tool for a specific purpose, and sometimes those tools have features and niceness that is hard to beat, but most of what I do professionally is just plain typing and I'm way more productive in emacs than any other typing tool.
Pretty cool that after all these years I can see an article like this and learn a thing or two as well. Thanks OP!