Eshell, Dired, Never learn Bash

Maybe no one told you, but Dired and Eshell go together. Try to learn just one without the other, and enlightenment will be tardy.

For faster enlightenment:

• Realize that there's effectively no prompt as far as the shell is concerned, they're just bookmarks for prompt nav commands. Try having a blank prompt for a while (prompt nav commands won't work) until it feels normal.
• Forbid cd. It's not sufficient to "try to use it less"; either run something like alias cd=echo in .bashrc, or have cd open a Dired buffer for the target.
• Forbid ls, or have ls just switch to the Dired buffer for that directory.
• Have a good hotkey in Dired to open the Shell buffer for the present directory, creating the buffer anew if necessary.
• Have a good hotkey in Shell to open the Dired buffer for the present directory—or you could content yourself with the ls command doing that.
• Previous Dired and Shell buffers should always bury themselves at the bottom of the buffer list! They would flood it otherwise.
• You'll notice that your shell buffers will be cleaner, with no trail of cd or ls output, and this may have made the scrollback more interesting. That ties into the next point: when using the shell, aim to never repeat a command. Decline to engage in the ancient workflow of iterating on shell commands, trying different switches and building pipes incrementally. In fact, you could set a counter for eshell-send-input (RET) such that you can only send 20 commands per day, and display this counter in the modeline or prompt.
  • Learn emacs-piper – it won't be needed as often as you think, but it's great as your last weapon.
  • Learn the hotkeys for navigating and manipulating the output. In particular:
    • C-c C-p – jump to previous prompt
    • C-M-l – similar, but jump to top of last output (better)
    • C-M-j – my-ins-oth-buf-fil-nam
    • C-c RET – more on this later
  • Instead of building pipes like ls -l | grep .jpg | cut -f1, use C-c M-o (eshell-mark-output), narrow-to-region and carry out the appropriate buffer-editing commands to get the same result that the shell command sequence would have. This is the hardest part by far, but the skills you gain in text transformation are general and carry over everywhere.
  • Learn to operate on the custom output you've munged – or even on any text, for example an Occur or EWW buffer – save it into a Lisp variable 'var, and access it as $var in eshell. Write custom functions to instantly pipe selected region to xargs. That sort of thing.

More, if you like going off the beaten path:

• Save the shell scrollback per directory
• Save the shell command history per directory
  • A side detail: keep track of the commands you've used the current session. They should be appended to the open directories' histories, regardless which directory they were used in.

if you follow the earlier advice, every directory already gets its own shell (remember that you disabled cd). With this last advice, when you enter a new directory's shell, you may be shown scrollback from weeks ago! Relevant or not, it can be fun to see, and anchors you in the passage of time. If you realize you wanted to use the output from earlier commands, from before you changed directory… simply go back to the previous directory's shell and grab it (hopping between shells should be a hotkey, that's faster than cd .. and cd -). Of course you'll still want the recent command history, things you used just minutes ago in another directory, which is why they should be brought along on the ride. The difference from usual history-tracking is that only the commands this session get saved to only those directories in which you have opened a shell, which is going to be a minority of all the directories you've visited with Dired.

I could ban the pipe (|) operator as part of a learning process for text munging.

Computing

AIMED AT: users who have gone through the basics and installed the system, but are still confused about things

Guix has not much in the way of end-user tutorials that tell you how to operate in day-to-day life. So you easily miss obvious things. We can't learn everything all at once nor see the best way to work even if we know roughly what commands exist. What follows would have prevented problems I had for far too long. Give it a gander in case you are suffering like I did.

I'd like to grow this list. If you have suggestions, email me!

guix pull
guix upgrade
sudo -E guix system reconfigure ~/config.scm

~/my-channel/me/emacs-xyz.scm
~/my-channel/me/machine-learning.scm
~/my-channel/me/various.scm
~/my-channel/.git

(cons*

  (channel
    (name 'me)
    (url "file:///home/me/my-channel/.git"))

  %default-channels)

guix package -L ~/my-channel -i MY-EXPERIMENTAL-PACKAGE

guix build -KM 5 -L ~/my-channel MY-EXPERIMENTAL-PACKAGE

alias test="guix package -KM 5 -L ~/my-channel -i "

There are many great packages. Packages like smartparens and company, that extend Emacs with invaluable functionality. But some packages are special, because they do more… they extend Emacs' extensibility. They increase Emacs' potential, make it applicable to more domains, let you slurp up more of your operating system and add opportunities for code reuse.

Some of them are:

• eshell
• exwm
• exwm-edit
• piper

These packages touch on a grander concept I will introduce shortly, but first I must explain what I see in Eshell.

The Way of Eshell is to abandon the concept of a terminal emulator, abandon the past and move into the future. The project has no plans to support escape codes (aka control codes) or interactive behavior, because controlling the shell buffer in realtime is considered out of scope for commands run by the shell.

Commands should be simple input-output machines and have no knowledge about their context. There is no need for each command to have twenty different command-line flags to shape the output into the form you want it – that's better done by an universal text-shaping tool, such as a text editor. You can alternatively use Unix commands like uniq, column and sort, but once you've exhausted what the commands can do, you may still have to make ad-hoc changes to the output as if in a text editor, so why not be in a text editor while you're doing it?

And better, once you're done editing the output with your everyday text-editing skills, you should be able to pipe it into another command without running into doubts as to which combination of echo, tee, xargs and cat applies this time (doubts strong enough that many have never thought of piping into vi). So you get to have a command pipeline without having to execute the pipeline in one step!

You don't need to iterate in a "compile-cycle" process until you get the whole pipeline just right. You can see what happens at each step, you don't need to pollute your shell history with irrelevant failed attempts, you can hone your text-editing arts, you'll have access to all the info your editor knows (say, the name of the file that's currently open in another window), you don't need to look up the specific shell commands to extract a specific piece of git information or system information (because you can get that info the same way you always do in your editor), and you'll never need to learn about commands like uniq, column or sort, or for that matter what even is Unix. Unix-nostalgia aside, that is scalable, beautiful and future-proof.

When you learn to abandon the Unix tools in favour of a more reusable and extensible workflow, you'll glimpse the deeper Zen underlying Emacs. The article Programs Are A Prison explains better than I can. Notice that it mentions that a good program should be "invisible", that it should lack boundaries, and eshell is a vivid example of that. Eshell is a much less distinct "application" than an external terminal window, and less distinct than ansi-term and even the polite shell mode. There is less of a sense that "Now I'm in the shell" or "Now I'm out of the shell". Its buffer is as malleable as any other buffer, and since you may do part of your command editing in separate buffers from eshell itself, it blurs the boundary of where the shell begins and ends.