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!
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.
> 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.
Did you check SBCL? It's pretty fast. On easy compiler, GCC and Clang are nightmare. Maybe TCC or cparser/cproc areen't, but the world it's full of stuff outside of C99.
Yup, very familiar with SBCL. But the truth is, to get SBCL to the point where it's anywhere near the realm of C for performance there's a ton of work that the compiler has to do that GCC simply doesn't.
Escape analysis to work out when heap allocations can be avoided, type inference to work out when dynamic type checks can be omitted / fixnum math can be used instead of generic math, when functions can be linked directly instead of dynamically dispatched, when functions are pure to allow for more flexible optimizations with evaluation order, etc.
Scheme adds even more complexity despite being a far smaller language than common lisp. Reified continuations massively complicate any optimzation and so does automatic lisp-1 to lisp-2 conversion, which has a bunch of caveats making it much trickier than it seems. Add on the fact that scheme lets you overwrite core primitive operations like car/cdr and there just isn't really any ground to stand on to prove anything about the code at all.
I have no idea how guile scheme runs as fast as it does.
GCC on the other hand is coming from a much better point of view: C is statically typed with full type signatures on every function, argument and variable, so you can safely eliminate all runtime type-checking and arity-checking. There's no garbage collection, so you don't need that. functions can't be redefined, and all must be declared before being used so you don't need a mechanism for dynamic dispatch, there's no closures so you don't need to perform any lambda lifting or closure conversion, you don't need the compiler or the interpreter available at runtime to handle calls to eval, loops are clearly marked and easy to optimize (vs lisp using tag-body and scheme using widespread recursion with TCO), fast iteration of lists in lisp requires the compiler to prove that it can safely eliminate a null check and C just doesn't do bounds checks, and so on.
There's an endless of list of reasons why it's easier to generate near-optimal assembly from C and why it's very hard to do so from lisp. A simple C compiler will produce far, far faster code than a simple lisp compiler.
> 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. :)
Die hard Unix users won't use Bash. Ksh maybe, and nvi, with tools like indent, entr to check the project directories and run simple makefiles (no, not gmake): git://bitreich.org/english_knight .
Bash it's too bloated, it can even do TCP/IP. Netcat can do that; or even Gawk in that case.
On Unix philosophy and Lisp, Forth shares a lot of that with decomposiing tools into words instead functions and word chaining instead of pipes.
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.
Get vidir, and spawn vidir from vim/nvi. It lets you use your editor as an interface to edit directorioes. Pretty fast to delete your files, or rename them.
> 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.
> 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.
You might be missing fzf from your toolbelt. Running `fzf --multi` does just that, and allows you to pipe the selection further to anything else you want to do.
This is why the shell is a more flexible environment. You don't need to adopt a large monolithic tool or drastically change your workflow to do something which you previously couldn't. You just need to insert another tool that does a single thing well into your existing pipelines, and your workflow can be improved with much less effort.
I use fzf as well, but I don't think it's quite comparable to the kind of ad hoc browsing we can do in a GUI desktop environment or in Emacs. Yes, 'fzf --multi' lets us select multiple files, but it's not really the same as casually browsing through a directory. For example, we might find an image file and preview it, or open a PDF just to skim it, and then mark that file and move on, and continue browsing files in this manner until we've gathered everything we need. That sort of exploratory, flexible interaction feels quite different.
Shell tools, Unix utilities, and 'fzf --multi' are definitely very powerful. But at least to me, they don't seem to offer the same kind of spontaneous browsing and editing experience, I'm referring to.
To be clear, this isn't some sort of competition! I'm not claiming one approach is superior to the other. Every tool has its strengths. My comments highlighting the features of Emacs do not imply that other tools are inferior. Quite the contrary!
I'm very fond of computing and I enjoy having a broad set of excellent tools at my disposal. The only point I disagree with is the claim that "all your examples are easily done in a shell". In my experience, the kind of random, ad hoc browsing, previewing, editing, marking and unmarking files, I'm talking about isn't quite as straightforward in the shell. It's certainly possible, but it doesn't feel as seamless or fluid as it does in Emacs. But again, this is not a competition. This is just an acknowledgement that different tools do different things!
I regularly rely on commands like 'find ... -exec', 'xargs', 'fzf', etc. But I also use Dired (and Emacs, in general) extensively. I find familiarity with both styles of tools very useful and the knowledge of both types of tools are transferable across a wide range of systems and environments.
Sure, fzf alone doesn't quite deliver the same UX if you need to visually preview the files. It does support sixel and other preview options though[1], and I'm sure that kind of workflow could be put together in other ways, but I can see how the experience would be better in a GUI tool. To be fair, I think this feature is not built into dired either and would require an additional package[2], so it still requires some customization as well.
> In my experience, the kind of random, ad hoc browsing, previewing, editing, marking and unmarking files, I'm talking about isn't quite as straightforward in the shell. It's certainly possible, but it doesn't feel as seamless or fluid as it does in Emacs. But again, this is not a competition.
Certainly. We should all use the tools we feel most comfortable with. And, frankly, the kind of visual selection you mentioned is not something I frequently do myself. In the rare cases I've had to, I was fine with a more rudimentary approach of previewing the files in whatever program can read them and mapping them to filenames manually. Doing this with dired, fzf with preview mode, or in a proper file manager, whether that's in a terminal with something like lf or in a more featureful GUI one, would've probably been faster.
That said, I was also objecting to your original claim that this cannot be easily done with standard Unix tools. At the end of the day, the choice of tools and what is easier to accomplish is subjective. I personally don't like relying on a single tool for my workflows, so I use Emacs strictly for editing text files. I even prefer the Git CLI over Magit, which is pretty blasphemous in the Emacs world. :) And I really like composing small purpose-built tools in the shell, especially if I can repurpose them in some way I hadn't done before, so using the shell instead of a file manager feels more natural to me. But they're all preferences, and it would be silly to claim that one is objectively inferior or superior to another.
> To be fair, I think this feature is not built into dired either and would require an additional package[2]
It is not part of Dired but it is part of Emacs, so it works out of the box. For example, in plain vanilla Emacs, if we type C-o on a PDF file displayed in Dired, it opens up the PDF file in a split window using doc-view. Similarly, if I type C-o on a PNG file, it opens up the PNG file using image-mode in a split window. So you're right that this isn't part of Dired but it is part of Emacs, so all of this works out of the box in vanilla Emacs with zero customisations.
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.
> 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.
Preference is definitely a factor, I agree with you there. But while a programming language is obviously more flexible technically, most people don't want to write a program to perform a task on their computer.
My point is that the shell is easier to script than writing Lisp (for most people; I'm sure Lisp nerds would disagree), and is more flexible than whatever facilities dired provides out of the box. To be fair, I haven't used dired more than a few times even though Emacs is my primary editor, but even if it emulates xargs or allows you to drop down to shell commands directly, it will never be as flexible for file operations as just using the shell.
The shell is not just a file manager. That's one of its primary features, sure, but it allows you to operate on files in an infinite number of ways. This is because it exposes fairly simple primitives that allow you to combine programs in ways that even their authors hadn't anticipated. This is why the do-one-thing-well philosophy is so powerful.
The famous Knuth-McIlroy story illustrates this well. Knuth created a sophisticated program to count words, which McIlroy replicated in a one-line shell script using a few UNIX tools. Knuth's was probably more correct, better documented, and handled edge cases better, but McIlroy's obviously required far less effort and would be easier to understand and expand. I don't think any tech geek or programmer would prefer writing a program for such relatively simple tasks.
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.
Okay, I can see the issue now, maybe I haven’t really used dired intensely enough for it to bother me. I just tried your snippet and having the cursor remain on the dired buffer for a quick preview is a feature I didn’t know I needed. Thanks for sharing!
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.
I got you. I like to be focused on a single thing so whatever is in front of me is relevant to the current task: Either selecting files or viewing them. So I've never been a fan of the file explorer windows/dock in most editors and IDEs.
In Vim, I use vinegar, which bind the minus key to display the file's directory in netrw and in netrw, go up.
Yes, I like to focus on one thing, too. That's why I usually only have one window and one buffer open to work on. The list-detail split view mode is when I want to quickly browse the files in a directory, like when I'm looking into a unfamiliar project.
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.
> "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.
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 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.
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?
dired-mode is fairly necessary in emacs to preserve the continuity of what you are editing.
For example, if I'm editing a file called originalfilename.txt, and I decide it should be called newfilename.txt, I can mv originalfilename.txt newfilename.txt in the terminal and it's all good, but you're still editing the buffer originalfilename.txt in emacs and if you save it you will have a new file with that name.
Using dired to change the filename updates all the buffers that are using that file.
dired gets some hate, I think because it creates a lot of buffers and they tend to stick around, but it's never bothered me.
> dired gets some hate, I think because it creates a lot of buffers and they tend to stick around, but it's never bothered me.
There's a variable in recent versions of emacs that deals with that
dired-kill-when-opening-new-dired-buffer
I'm glad it's a switch, though. I set it to true, but I can see someone being used to the dired command to go to a specific directory, and then manage things with dired-insert-subdir.
I'm also an emacs user in the habit of using the shell for file management, and I just deal with this mismatch. It hasn't been annoying enough for me to solve by switching to something else. But then again, I guess I don't do a lot "file management", whatever that really means.
I think it's pretty easy to learn to just M-x dired compared to however you switch to terminal in these cases and probably would be worth it. I guess we're using this "file management" term to mean delete or move - it's whatever you want it to be.
How many editors can you think of that don't do any (strictly) unnecessary file operations, e.g. renaming files? The author's problem is that Emacs is just really good at it, so he wants to use it more.
I'd call it more than a shell. It's more like a text oriented Lisp (Emacs Lisp to be specific) runtime environment with built in editing, interpretation, compilation, and debugging tools. It's also been a popular home for numerous applications that have found lives of their own, far beyond editing text.
I like to call it a generalized interface to information.
The web of the early 1990s could be called the same thing, but not the modern web, which is more like a "generalized experience-delivery platform with an old much-simpler generalized interface to information at its core".
It gives me fewer reasons to leave Emacs. Which increases my productivity. There's very little 'mental context switch' delay since it's all the same tool with the same interface.
An OS may be too much but, as a proof of concept, there are people who have been running Emacs as PID 1. And I don't mean in an OCI container (we're used to have only one process there): I mean on the bare metal, with Emacs being PID 1. A bit radical but it's been done.
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!
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>.
IMO a nice demo of wdired (writable dired) should be enough to convince anyone to switch to emacs :)
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.
> 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.
Did you check SBCL? It's pretty fast. On easy compiler, GCC and Clang are nightmare. Maybe TCC or cparser/cproc areen't, but the world it's full of stuff outside of C99.
Yup, very familiar with SBCL. But the truth is, to get SBCL to the point where it's anywhere near the realm of C for performance there's a ton of work that the compiler has to do that GCC simply doesn't.
Escape analysis to work out when heap allocations can be avoided, type inference to work out when dynamic type checks can be omitted / fixnum math can be used instead of generic math, when functions can be linked directly instead of dynamically dispatched, when functions are pure to allow for more flexible optimizations with evaluation order, etc.
Scheme adds even more complexity despite being a far smaller language than common lisp. Reified continuations massively complicate any optimzation and so does automatic lisp-1 to lisp-2 conversion, which has a bunch of caveats making it much trickier than it seems. Add on the fact that scheme lets you overwrite core primitive operations like car/cdr and there just isn't really any ground to stand on to prove anything about the code at all.
I have no idea how guile scheme runs as fast as it does.
GCC on the other hand is coming from a much better point of view: C is statically typed with full type signatures on every function, argument and variable, so you can safely eliminate all runtime type-checking and arity-checking. There's no garbage collection, so you don't need that. functions can't be redefined, and all must be declared before being used so you don't need a mechanism for dynamic dispatch, there's no closures so you don't need to perform any lambda lifting or closure conversion, you don't need the compiler or the interpreter available at runtime to handle calls to eval, loops are clearly marked and easy to optimize (vs lisp using tag-body and scheme using widespread recursion with TCO), fast iteration of lists in lisp requires the compiler to prove that it can safely eliminate a null check and C just doesn't do bounds checks, and so on.
There's an endless of list of reasons why it's easier to generate near-optimal assembly from C and why it's very hard to do so from lisp. A simple C compiler will produce far, far faster code than a simple lisp compiler.
> 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. :)
Die hard Unix users won't use Bash. Ksh maybe, and nvi, with tools like indent, entr to check the project directories and run simple makefiles (no, not gmake): git://bitreich.org/english_knight .
Bash it's too bloated, it can even do TCP/IP. Netcat can do that; or even Gawk in that case.
On Unix philosophy and Lisp, Forth shares a lot of that with decomposiing tools into words instead functions and word chaining instead of pipes.
“shell” would have been the right word to use instead of “bash”, but it’s immaterial to the point.
So it is similar to Total Commander, but in editor. Or Double Commander…
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.
Get vidir, and spawn vidir from vim/nvi. It lets you use your editor as an interface to edit directorioes. Pretty fast to delete your files, or rename them.
> 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.
> 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.
You might be missing fzf from your toolbelt. Running `fzf --multi` does just that, and allows you to pipe the selection further to anything else you want to do.
This is why the shell is a more flexible environment. You don't need to adopt a large monolithic tool or drastically change your workflow to do something which you previously couldn't. You just need to insert another tool that does a single thing well into your existing pipelines, and your workflow can be improved with much less effort.
I use fzf as well, but I don't think it's quite comparable to the kind of ad hoc browsing we can do in a GUI desktop environment or in Emacs. Yes, 'fzf --multi' lets us select multiple files, but it's not really the same as casually browsing through a directory. For example, we might find an image file and preview it, or open a PDF just to skim it, and then mark that file and move on, and continue browsing files in this manner until we've gathered everything we need. That sort of exploratory, flexible interaction feels quite different.
Shell tools, Unix utilities, and 'fzf --multi' are definitely very powerful. But at least to me, they don't seem to offer the same kind of spontaneous browsing and editing experience, I'm referring to.
To be clear, this isn't some sort of competition! I'm not claiming one approach is superior to the other. Every tool has its strengths. My comments highlighting the features of Emacs do not imply that other tools are inferior. Quite the contrary!
I'm very fond of computing and I enjoy having a broad set of excellent tools at my disposal. The only point I disagree with is the claim that "all your examples are easily done in a shell". In my experience, the kind of random, ad hoc browsing, previewing, editing, marking and unmarking files, I'm talking about isn't quite as straightforward in the shell. It's certainly possible, but it doesn't feel as seamless or fluid as it does in Emacs. But again, this is not a competition. This is just an acknowledgement that different tools do different things!
I regularly rely on commands like 'find ... -exec', 'xargs', 'fzf', etc. But I also use Dired (and Emacs, in general) extensively. I find familiarity with both styles of tools very useful and the knowledge of both types of tools are transferable across a wide range of systems and environments.
Sure, fzf alone doesn't quite deliver the same UX if you need to visually preview the files. It does support sixel and other preview options though[1], and I'm sure that kind of workflow could be put together in other ways, but I can see how the experience would be better in a GUI tool. To be fair, I think this feature is not built into dired either and would require an additional package[2], so it still requires some customization as well.
> In my experience, the kind of random, ad hoc browsing, previewing, editing, marking and unmarking files, I'm talking about isn't quite as straightforward in the shell. It's certainly possible, but it doesn't feel as seamless or fluid as it does in Emacs. But again, this is not a competition.
Certainly. We should all use the tools we feel most comfortable with. And, frankly, the kind of visual selection you mentioned is not something I frequently do myself. In the rare cases I've had to, I was fine with a more rudimentary approach of previewing the files in whatever program can read them and mapping them to filenames manually. Doing this with dired, fzf with preview mode, or in a proper file manager, whether that's in a terminal with something like lf or in a more featureful GUI one, would've probably been faster.
That said, I was also objecting to your original claim that this cannot be easily done with standard Unix tools. At the end of the day, the choice of tools and what is easier to accomplish is subjective. I personally don't like relying on a single tool for my workflows, so I use Emacs strictly for editing text files. I even prefer the Git CLI over Magit, which is pretty blasphemous in the Emacs world. :) And I really like composing small purpose-built tools in the shell, especially if I can repurpose them in some way I hadn't done before, so using the shell instead of a file manager feels more natural to me. But they're all preferences, and it would be silly to claim that one is objectively inferior or superior to another.
Cheers!
[1]: https://github.com/junegunn/fzf?tab=readme-ov-file#previewin...
[2]: https://github.com/protesilaos/dired-preview
> To be fair, I think this feature is not built into dired either and would require an additional package[2]
It is not part of Dired but it is part of Emacs, so it works out of the box. For example, in plain vanilla Emacs, if we type C-o on a PDF file displayed in Dired, it opens up the PDF file in a split window using doc-view. Similarly, if I type C-o on a PNG file, it opens up the PNG file using image-mode in a split window. So you're right that this isn't part of Dired but it is part of Emacs, so all of this works out of the box in vanilla Emacs with zero customisations.
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.
> 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.
Preference is definitely a factor, I agree with you there. But while a programming language is obviously more flexible technically, most people don't want to write a program to perform a task on their computer.
My point is that the shell is easier to script than writing Lisp (for most people; I'm sure Lisp nerds would disagree), and is more flexible than whatever facilities dired provides out of the box. To be fair, I haven't used dired more than a few times even though Emacs is my primary editor, but even if it emulates xargs or allows you to drop down to shell commands directly, it will never be as flexible for file operations as just using the shell.
The shell is not just a file manager. That's one of its primary features, sure, but it allows you to operate on files in an infinite number of ways. This is because it exposes fairly simple primitives that allow you to combine programs in ways that even their authors hadn't anticipated. This is why the do-one-thing-well philosophy is so powerful.
The famous Knuth-McIlroy story illustrates this well. Knuth created a sophisticated program to count words, which McIlroy replicated in a one-line shell script using a few UNIX tools. Knuth's was probably more correct, better documented, and handled edge cases better, but McIlroy's obviously required far less effort and would be easier to understand and expand. I don't think any tech geek or programmer would prefer writing a program for such relatively simple tasks.
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.
1: https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
Like vidir for any Unix tools, you can get vidir from the 'moreutils' package. A must have under the Unix toolchest, among entr and friends.
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.
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.
Okay, I can see the issue now, maybe I haven’t really used dired intensely enough for it to bother me. I just tried your snippet and having the cursor remain on the dired buffer for a quick preview is a feature I didn’t know I needed. Thanks for sharing!
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.
I got you. I like to be focused on a single thing so whatever is in front of me is relevant to the current task: Either selecting files or viewing them. So I've never been a fan of the file explorer windows/dock in most editors and IDEs.
In Vim, I use vinegar, which bind the minus key to display the file's directory in netrw and in netrw, go up.
Yes, I like to focus on one thing, too. That's why I usually only have one window and one buffer open to work on. The list-detail split view mode is when I want to quickly browse the files in a directory, like when I'm looking into a unfamiliar project.
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.
Can you copy a line and paste it in a different directory to copy a file?
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.
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.
> "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).
If you just do C-x C-f, M-n to get the "next completion" gives you the file at point.
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.
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 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.
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?
Slight nitpick: It’s no longer called a “MIME Type”, it’s now called an “Internet Media Type”.
My file manager is the shell and the utilities like cp, mv, rm, find, xargs, grep, etc.
Have never felt the need for anything beyond that.
Just because you've never felt the need doesn't mean you aren't stuck in a local minimum.
I feel exactly the same, but a sibling comment reminded me how I got there.
I didn't need a replacement for Windows Explorer, until I tried Linux (bash, really) out of boredom/curiosity, and now I can't imagine going back.
Could be that there's another step up. And we can't see it from where we are standing.
dired-mode is fairly necessary in emacs to preserve the continuity of what you are editing.
For example, if I'm editing a file called originalfilename.txt, and I decide it should be called newfilename.txt, I can mv originalfilename.txt newfilename.txt in the terminal and it's all good, but you're still editing the buffer originalfilename.txt in emacs and if you save it you will have a new file with that name.
Using dired to change the filename updates all the buffers that are using that file.
dired gets some hate, I think because it creates a lot of buffers and they tend to stick around, but it's never bothered me.
> dired gets some hate, I think because it creates a lot of buffers and they tend to stick around, but it's never bothered me.
There's a variable in recent versions of emacs that deals with that
I'm glad it's a switch, though. I set it to true, but I can see someone being used to the dired command to go to a specific directory, and then manage things with dired-insert-subdir.Useful for tramp wireguard dired too I think. Have to investigate.
I'm also an emacs user in the habit of using the shell for file management, and I just deal with this mismatch. It hasn't been annoying enough for me to solve by switching to something else. But then again, I guess I don't do a lot "file management", whatever that really means.
I think it's pretty easy to learn to just M-x dired compared to however you switch to terminal in these cases and probably would be worth it. I guess we're using this "file management" term to mean delete or move - it's whatever you want it to be.
The insanity of trying to shoehorn everything into emacs, even calling it an OS, is purely beyond.
Once you realize that elisp is a better shell programming language than bash, it ceases to appear insane.
I much prefer them to the people that try to shoehorn everything user-facing into the browser.
s/browser/llm
How many editors can you think of that don't do any (strictly) unnecessary file operations, e.g. renaming files? The author's problem is that Emacs is just really good at it, so he wants to use it more.
Emacs is a shell, not an OS. It's an extremely customizable and programmable shell that works with many third-party utilities, but it's still a shell.
I'd call it more than a shell. It's more like a text oriented Lisp (Emacs Lisp to be specific) runtime environment with built in editing, interpretation, compilation, and debugging tools. It's also been a popular home for numerous applications that have found lives of their own, far beyond editing text.
I like to call it a generalized interface to information.
The web of the early 1990s could be called the same thing, but not the modern web, which is more like a "generalized experience-delivery platform with an old much-simpler generalized interface to information at its core".
It gives me fewer reasons to leave Emacs. Which increases my productivity. There's very little 'mental context switch' delay since it's all the same tool with the same interface.
An OS may be too much but, as a proof of concept, there are people who have been running Emacs as PID 1. And I don't mean in an OCI container (we're used to have only one process there): I mean on the bare metal, with Emacs being PID 1. A bit radical but it's been done.