I didn't see this mentioned in the article, so I thought I would mention it here:
Dired stands for directory editing.
One of my favourite features of Dired is the ability to mark or unmark multiple files in a variety of ways: manually, using repetition counts, or with regular expressions. This can be done fluidly and spontaneously as we browse and inspect files. Once we're satisfied with our selection, we can perform bulk operations on them such as copying, moving, deleting, changing permission bits, compressing the marked files, etc.
It's a bit like how we can use a GUI desktop environment to mark multiple files and then perform bulk operations on them. This is something we cannot easily do on the shell with the standard Unix utilities. But we can do all of this from within Emacs using very concise sequence of keystrokes and muscle memory.
Further, unlike most GUI desktop environments, every Dired interaction is scriptable, recordable, and replayable. I mean every operation or key sequence in Dired is available as an Elisp function, so we can script repetitive tasks by writing small Elisp snippets. Or, alternatively, we can have Emacs record the repetitive actions as keyboard macros, which we can then replay as many times as needed. I no longer have to worry whether the underlying GUI desktop environment supports these features or not because I know Emacs does and I can just use Emacs to browse my system.
And that brings me to another important benefit of using Dired: my muscle memory for Dired is transferable across a wide variety of systems and environments. It doesn't matter whether I'm working locally or logged into a remote shell, or whether I'm on macOS, Xfce4, KDE, etc. I can browse and edit my files and directories in exactly the same way using the same muscle memory and the same set of Dired commands, key sequences, and features!
> One of my favourite features of Dired is the ability to mark or unmark multiple files in a variety of ways: manually, using repetition counts, or with regular expressions. This can be done fluidly and spontaneously as we browse and inspect files. Once we're satisfied with our selection, we can perform bulk operations on them such as copying, moving, deleting, changing permission bits, compressing the marked files, etc.
That does sound cool. Emacs sounds like the type of app I would have loved back when DOS was still a thing, but now after using linux for 20 something years, the fact that it can do everything just seems so antithetical to the unix way...even if I could see myself using it, the idea of being so dependent on one app for so much seems so weird to me these days. Guess I'll be sticking with vim and various cli tools until the end of time.
Emacs isn't really a follower of the unix philosophy since it's more a hold-over from the world of lisp machines.
Emacs also eschews the "everything is a file" philosophy of unix (programs in emacs are just lisp functions) and the idea of storing / transmitting data as plain text, instead using lisp data structures to do that.
Lisp itself is kind of antithetical to the unix philosophy too when compared with C. Lisp is presents an extremely simple, totally consistent core that is extremely difficult to implement efficient compilers for. C on the other hand was designed from the outset with the goal of being easy to write compilers for. Requirements for having function prototypes ahead of uses, having all variables declared at the top of a function, etc were done to make it easier to implement. Almost a perfect example of worse is better, really.
Check out the unix hater's handbook if you haven't, that sums up pretty nicely the world that emacs hails from.
> now after using linux for 20 something years, the fact that it can do everything just seems so antithetical to the unix way...even if I could see myself using it, the idea of being so dependent on one app for so much seems so weird to me these days. Guess I'll be sticking with vim and various cli tools until the end of time.
I used to feel the same, after using Linux and Vim for 15 years. But then I switched to Emacs 6 years ago; initially as an experiment, but I couldn’t go back to Vim after trying Org-mode and other packages.
Now my perspective has changed. Emacs at its core is not one program, in a sense. It is a Lisp interpreter with a GUI, that ships with thousands of ready-to-use Elisp programs that share common conventions for user interfaces, key bindings, extensions, and configuration. But you don’t run all those programs at once, only the ones you need, and the rest of the “bloat” is not used. So in that sense it does feel more like an operating system than a program, in a good way.
But Emacs itself is modular in a way similar to Unix. Just that instead of being modular in the sense of many executables exchanging text streams, it is modular in the sense of many Elisp programs passing lists or buffers around. The Unix philosophy implemented at another layer of abstraction, in a sense.
EDIT: Dired mentioned here is a good example: It is a file manager implemented as a separate "Elisp program" that communicates with coreutils under the hood.
Emacs, and GNU at large, never cared for Eric Raymond's idea of "do one thing and one thing only" being the Unix way. They freely make large do-everything programs.
I think you would find that the primitives emacs lets you compose are not so different from the primitives bash lets you compose, just more syntactic and less, you know, clunky. :)
Not so sure. I like and use wdired, but `vidir` from `moreutils` is almost as useful and works with any editor. I used it for a decade before trying Emacs and didn’t feel like I was missing out.
Just that it’s all done from the comfort of the editor one knows and loves, with the same key binding and semantics that at there, whether you edit files in fired, write code, a commit message or an email.
Not to get too deep into this, but there’s this warm fuzzy feeling of not having to use /yet another different app/ that’s ever so slightly different to the optimal workflow you have otherwise
One difference (I assume?): it’s programmable. It’s a directory editor written in the same VM in which the editor (Emacs) is written. This makes it compostable with your existing IDE toolset of macros, plugins, hotkeys, etc.
For example: I never thought of using total commander to augment some custom hotkey in vim. But in Emacs it’s just another set of functions available right there.
> This is something we cannot easily do on the shell with the standard Unix utilities.
Huh? All your examples are easily done in a shell. GNU find and fd support regex, xargs can be used for bulk operations, etc. This is more flexible and scriptable than anything dired allows you to do. It might not be immediately easier, but once you grasp how a few basic shell utilities work and how to combine them, using shell history, functions, aliases, and key bindings becomes part of your muscle memory. This workflow is even more transferable across systems and environments.
I think dired is convenient if you're already using Emacs and want to do a quick operation, but the shell is far more generally useful in the long run.
> GNU find and fd support regex, xargs can be used for bulk operations, etc.
I don't see how this is comparable to arbitrarily browsing through a directory, inspecting files, and manually marking the ones you want to act on. The feature I was describing is more akin to how we browse directories in a graphical desktop environment.
I use find, xargs, and similar tools as well, but they don't allow you to casually mark or unmark files and run operations on them later. With these tools, you need a fairly precise idea of what you're targeting. Then you have to write a glob or regex pattern up front, and then execute the command. That's a very different workflow from interactively exploring a directory, making ad-hoc decisions, and selectively marking files as you go.
It's hard to explain thoroughly, but Emacs is basically doing exactly what you say, except interactively.
Instead of typing up an entire command pipeline all at once, or running sections of the pipeline into temporary files that you examine/edit with a text editor, Emacs lets you run that same pipeline interactively in a text buffer (basically a temporary file). Being able to see the results as you work on it interactively is a huge advantage (compare ed vs vi).
On top of that, BSD had a standalone 'dired' in the late 80s and Linux moreutils (not quite a standard, but certainly widespread) contains 'vidir' - which, despite the slightly misleading name, allows you to visually edit a directory with whatever your EDITOR env var points to.
As you say, none of them do anything that can't be done with find and xargs (and perhaps a little awk and sed), but they're occasionally handy for one-off operations.
If you prefer the command-line and Unix shell, that’s one thing, but it’s no more “flexible or scriptable” than Emacs and Lisp.
Dired can filter files with regexp; you can even fall back on GNU ‘find’ (‘find-dired’). And you can execute shell commands on filtered files in Dired (‘&’), it’s like xargs without the confusing syntax—but, of course, you can just run ‘xargs’ from it, if that’s what you prefer.
A graphical file-manager is, I find, a much nicer interface for file-management than the command-line. I see all filtered files, and I can view and edit them anytime, as I please. With the command-line, it’s like I’m working with blindfolds on.
Dired can be a nice refuge even if you’re a command-line junkie, because in-spite of its own commands (abstracting the shell), you can always drop back to the shell, as you please. Funnily enough, my usage of Dired vis-à-vis the shell is kind of the inverse of what you described, I use the shell for either quick or really complicated operations and Dired for everything else—which ends up being over 95% of my use.
I use dired for a long time now and at first it felt a bit weird but not anymore. The ultimate killer feature is wdired [1] that make the dired buffer writeable and you can edit text/filenames/permissions like in any other emacs buffer and commit the changes with C-c C-c.
In dired-mode, I want to have a split view of the directory listing on the left window and to quickly browse the content of each file on the right window. The default file visit command keeps opening a new window for each file which needs closing. It's really annoying. I put the following in init.el file and bind it to a key. It loads the current file under the cursor in the next existing window on right, on left, above, below, or opening a new window as needed.
;; In dired mode, visit the file at the cursor in the right/below/left/above window.
(defun my-dired-display-direction ()
(interactive)
(let* ((file-or-dir (dired-get-file-for-visit)) ;; get the file at cursor
(buffer (find-file-noselect file-or-dir))) ;; load the file into a buffer
(let ((window ;; figure out the window to use
(cond ((get-buffer-window buffer (selected-frame)))
((window-in-direction 'right)) ;; try window in each direction
((window-in-direction 'below)) ;; and default to right
((window-in-direction 'left)) ;; if no window found.
((window-in-direction 'above))
(t (split-window (selected-window) nil 'right)))))
(window--display-buffer buffer window 'window nil)
window)) )
;; Bind ctrl-o to display at direction.
(define-key dired-mode-map (kbd "C-o") 'my-dired-display-direction)
I guess you already know the command `dired-find-file-other-window` (bound to `o` by default), which reuses the right split window, if already there and opens a new window if there is none. Horizontal splits do not seem to be reused though (they often don’t have enough vertical space for dired anyway, which is why I guess they designed it this way).
Yes. dired-find-file-other-window is the one I found annoying. It moves the cursor/focus to the other window, and it keeps opening new split windows. If I ran the cmd 3 times, it would open 3 new split windows. Really annoying.
I want the cursor/focus to remain on the dired window so that I can go down the file list and see the file content on the other window. Ctrl-n and ctrl-o are all I need to do.
An alternative workflow I use is the dired-view-file bound to 'v' to have a read-only buffer for the file which you can scroll through with <space> and other such keys. Then you can use 'q' to close the buffer and 'e' to edit it.
Yes, that works but the view window takes up the whole frame. I want the dired window remains and the cursor/focus to remain in the dired window so that I can go down the file list and see the file content on the other window. Ctrl-n and ctrl-o are all I need to do.
> "Opening them from dired-mode already puts them into emacs, so"
This also works globally with #'find-file-at-point (which isn't bound to a hotkey by default, but should be: this is one of my most satisfying hotkeys. That function opens any filepath appearing as a string, in any context, in the working directory of that context—filepath strings in files, and filepath strings as outputs from shell commands, being the top two).
(It's like converting every file reference into a clickable URL—only, implicitly).
This works really well together with Embark (https://github.com/oantolin/embark) as well. C-. then RET to open the file, or any other action you'd like to perform on it.
wdired-change-to-wdired-mode, FTW! :-) An extremely cool feature is dired buffers are editable for changing file names and permissions. You can even use this feature, en masse, with other features like rectangle edit.
I've never tried that but copying files via two different dired buffer is trivial. It is also really useful for copying files to and from remote hosts via tramp. (If copying large files in this manner look into rsync versus ssh.) Here is my .emacs if you want to see it: https://github.com/julienchastang/dotemacs/blob/master/setti.... It is a continuous work in progress.
The most amazing part of guix (and nixOS) is that you can just copy that piece of code into your home-config.scm and have it running in a few seconds. It's pretty mind blowing.
my absolute favorite feature of dired is rw mode (^x ^q) - edit your dir like a normal text file. use regex replacement, macros with counters, multi cursor - whatever you like. See the result of your edits, commit bam. much more fun than piping find through something
The one thing I miss about dired-x is being able to edit multiple filenames simultaneously in the same way you do edit a file using multiple cursors, and commit the changes all at once. Can someone make that work in Windows Explorer or VS Code please?
Readit News
Dired stands for directory editing.
One of my favourite features of Dired is the ability to mark or unmark multiple files in a variety of ways: manually, using repetition counts, or with regular expressions. This can be done fluidly and spontaneously as we browse and inspect files. Once we're satisfied with our selection, we can perform bulk operations on them such as copying, moving, deleting, changing permission bits, compressing the marked files, etc.
It's a bit like how we can use a GUI desktop environment to mark multiple files and then perform bulk operations on them. This is something we cannot easily do on the shell with the standard Unix utilities. But we can do all of this from within Emacs using very concise sequence of keystrokes and muscle memory.
Further, unlike most GUI desktop environments, every Dired interaction is scriptable, recordable, and replayable. I mean every operation or key sequence in Dired is available as an Elisp function, so we can script repetitive tasks by writing small Elisp snippets. Or, alternatively, we can have Emacs record the repetitive actions as keyboard macros, which we can then replay as many times as needed. I no longer have to worry whether the underlying GUI desktop environment supports these features or not because I know Emacs does and I can just use Emacs to browse my system.
And that brings me to another important benefit of using Dired: my muscle memory for Dired is transferable across a wide variety of systems and environments. It doesn't matter whether I'm working locally or logged into a remote shell, or whether I'm on macOS, Xfce4, KDE, etc. I can browse and edit my files and directories in exactly the same way using the same muscle memory and the same set of Dired commands, key sequences, and features!
A couple of years ago, I used to host Emacs book club meetings. I've kept some notes on directory editing with Dired from those sessions here: <https://susam.net/cc/mastering-emacs/ch06.html#dired>.
That does sound cool. Emacs sounds like the type of app I would have loved back when DOS was still a thing, but now after using linux for 20 something years, the fact that it can do everything just seems so antithetical to the unix way...even if I could see myself using it, the idea of being so dependent on one app for so much seems so weird to me these days. Guess I'll be sticking with vim and various cli tools until the end of time.
Emacs also eschews the "everything is a file" philosophy of unix (programs in emacs are just lisp functions) and the idea of storing / transmitting data as plain text, instead using lisp data structures to do that.
Lisp itself is kind of antithetical to the unix philosophy too when compared with C. Lisp is presents an extremely simple, totally consistent core that is extremely difficult to implement efficient compilers for. C on the other hand was designed from the outset with the goal of being easy to write compilers for. Requirements for having function prototypes ahead of uses, having all variables declared at the top of a function, etc were done to make it easier to implement. Almost a perfect example of worse is better, really.
Check out the unix hater's handbook if you haven't, that sums up pretty nicely the world that emacs hails from.
I used to feel the same, after using Linux and Vim for 15 years. But then I switched to Emacs 6 years ago; initially as an experiment, but I couldn’t go back to Vim after trying Org-mode and other packages.
Now my perspective has changed. Emacs at its core is not one program, in a sense. It is a Lisp interpreter with a GUI, that ships with thousands of ready-to-use Elisp programs that share common conventions for user interfaces, key bindings, extensions, and configuration. But you don’t run all those programs at once, only the ones you need, and the rest of the “bloat” is not used. So in that sense it does feel more like an operating system than a program, in a good way.
But Emacs itself is modular in a way similar to Unix. Just that instead of being modular in the sense of many executables exchanging text streams, it is modular in the sense of many Elisp programs passing lists or buffers around. The Unix philosophy implemented at another layer of abstraction, in a sense.
EDIT: Dired mentioned here is a good example: It is a file manager implemented as a separate "Elisp program" that communicates with coreutils under the hood.
Deleted Comment
Not to get too deep into this, but there’s this warm fuzzy feeling of not having to use /yet another different app/ that’s ever so slightly different to the optimal workflow you have otherwise
For example: I never thought of using total commander to augment some custom hotkey in vim. But in Emacs it’s just another set of functions available right there.
Huh? All your examples are easily done in a shell. GNU find and fd support regex, xargs can be used for bulk operations, etc. This is more flexible and scriptable than anything dired allows you to do. It might not be immediately easier, but once you grasp how a few basic shell utilities work and how to combine them, using shell history, functions, aliases, and key bindings becomes part of your muscle memory. This workflow is even more transferable across systems and environments.
I think dired is convenient if you're already using Emacs and want to do a quick operation, but the shell is far more generally useful in the long run.
I don't see how this is comparable to arbitrarily browsing through a directory, inspecting files, and manually marking the ones you want to act on. The feature I was describing is more akin to how we browse directories in a graphical desktop environment.
I use find, xargs, and similar tools as well, but they don't allow you to casually mark or unmark files and run operations on them later. With these tools, you need a fairly precise idea of what you're targeting. Then you have to write a glob or regex pattern up front, and then execute the command. That's a very different workflow from interactively exploring a directory, making ad-hoc decisions, and selectively marking files as you go.
Instead of typing up an entire command pipeline all at once, or running sections of the pipeline into temporary files that you examine/edit with a text editor, Emacs lets you run that same pipeline interactively in a text buffer (basically a temporary file). Being able to see the results as you work on it interactively is a huge advantage (compare ed vs vi).
As you say, none of them do anything that can't be done with find and xargs (and perhaps a little awk and sed), but they're occasionally handy for one-off operations.
Dired can filter files with regexp; you can even fall back on GNU ‘find’ (‘find-dired’). And you can execute shell commands on filtered files in Dired (‘&’), it’s like xargs without the confusing syntax—but, of course, you can just run ‘xargs’ from it, if that’s what you prefer.
A graphical file-manager is, I find, a much nicer interface for file-management than the command-line. I see all filtered files, and I can view and edit them anytime, as I please. With the command-line, it’s like I’m working with blindfolds on.
Dired can be a nice refuge even if you’re a command-line junkie, because in-spite of its own commands (abstracting the shell), you can always drop back to the shell, as you please. Funnily enough, my usage of Dired vis-à-vis the shell is kind of the inverse of what you described, I use the shell for either quick or really complicated operations and Dired for everything else—which ends up being over 95% of my use.
1: https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
I want the cursor/focus to remain on the dired window so that I can go down the file list and see the file content on the other window. Ctrl-n and ctrl-o are all I need to do.
This also works globally with #'find-file-at-point (which isn't bound to a hotkey by default, but should be: this is one of my most satisfying hotkeys. That function opens any filepath appearing as a string, in any context, in the working directory of that context—filepath strings in files, and filepath strings as outputs from shell commands, being the top two).
(It's like converting every file reference into a clickable URL—only, implicitly).
Oil.nvim provides an incredible experience for managing files. It'll even use the LSP to fix imports if you move files from place to place.