The previous post gave an overview of the 2 approaches with a technical stack and a practical conclusion. Here, I would like to explore how each approach integrates data.
While the Unix philosophy is often quoted as "do one thing well", Doug McIlroy in 1978
also mentions output should be clean enough to be the input of other programs. It's quite easy to see how command-line tools fit this by allowing data to be piped from one program to another.
However, Emacs does also a similar thing, but in its own ecosystem. In Emacs, everything is a text buffer, allowing for complex but smooth text manipulation with existing packages or ever homemade lisp functions. For example, within eshell,
output of a command can be redirected into a buffer, where it can be edited seamlessly without leaving emacs. More complex actions
can be done by exploiting lisp functions too. Minibuffer operations is also a powerful tool, thanks to the embark
emacs package. For example, it allows you to select a list of files and open all of them at once, each in its own pane. Its action model is powerful
but need some time to make it click.
Let us take a step back from text manipulation and assume you are living inside Emacs. Reading your mail with notmuch, you notice a new mail from your boss asking for a quick review of a new research topic. This requires some thought so you cannot deal with it right now. As you follow the Getting Thing Done philosophy, you aim for an empty inbox so you would like to place the mail in your todo list. With org-mode, you can store a link to the mail and add it to a new task. Using capture, you quicky open a popup and insert the link to mail. Later in the day, you prepare the answer by looking on your notes for a few papers. Thanks to the citar, you can open the paper as a PDF and check your bibliography notes stored in denote. As you can see, there is tight integration on the text but also "app" level in Emacs.
Obviously, those nice smooth workflows require staying in Emacs. There are diminishing returns the longer you spend your time outside Emacs. Now, can we replicate this on the command-line ?
I would argue we can, to some extent, manage reasonably tight coupling on the command-line.
The true power comes from combining classic GNU tools, like grep, find
or their more recent rewrites in Rust, like ripgrep, fd
and so on. As a simple example, if you are a Zettelkasten user, cleaning-up your notes by looking for stale notes -- not modified in the last 5 months -- can be done with nvim $(find . -mtime +150 -type f).
There is no direct equivalent of minibuffer interaction but fzf
is a close candidate to interactively select data. As an example, we can emulate wgrep
functionality by interactively selecting files containing a search pattern.
A strong use case for CLI workflow is data processing on text files. In bioinformatics, data is often stored at text, either plain or archived. A mixture of find, awk
and grep
can get you quite far
to quickly analyze data and gnuplot
allows for graphical exploratory analysis.
It is possible to use more specialized tools, like qsv
for CSV processing, but I find it harder to learn one syntax per tool. As an alternative, I prefer the unified approach of nushell, a shell that can read JSON, XML, CSV or even SQL databases into a tabular format with powerful directives.
While there are tools to emulate an Emacs-like workflow (see my stack), integration at a higher level is less smooth on the terminal.
However, running dedicated actions, like adding a task with taskwarrior
or a journal entry with jrnl, before resuming your work suits my mental model of staying focused on a single task. Both approaches lend themselves well to the hacker spirit of quickly testing new tools and building your own if needed.