Re: [dev] Is there a text editor following the UNIX philosophy?

From: Jonathan Bakke <>
Date: Sat, 12 Feb 2022 18:42:06 +0000

On Fri, Feb 11, 2022 at 3:47 AM, Daniel Littlewood <> wrote:

> ...

> From the other end, there is always ed.
> Unfortunately I don't have much experience with it, and it's not often
> discussed, so I can't tell whether it could do the "integration" step.
> I wonder whether there are any text-editing (particularly
> code-editing) workflows people have had success with which combine
> many small programs, rather than using a single monolith.

I use ed. Each tool is specialized, though.

I prefer vi-like editing for fixing typos. Having visual feedback drastically reduces errors from commands like sed.

For multiple changes of the same sort, though, sed is better. I write a draft of the editing command, verify that it does what I want on standard output, then repeat the command with it overwriting the file.

awk is nicer than sed at picking out parts of lines -- back references, in regex-speak. For anything more than a one-line script, though, I prefer to write something in C, but that just comes down to a question of familiarity. Use Perl or Python, anything that you're comfortable with... but don't avoid the right tool only because you haven't yet learned to use it comfortably. I've tried using shell scripts for direct text manipulation -- that way lies madness -- but collating utilities with the shell is the indispensable feature that IDEs try to dispose of. That means learning how to use lots of utilities.

grep is better than any in-editor find tool I've used. Line numbers are the bridge between grep and your editor of choice... between most utilities, actually. 'find -exec grep' is better than any in-IDE find tool I've used. And sed, of course, fills the role of replace.

An alias that runs { grep | tee tempfile } can be useful to automatically save your searches to review later or iterate over, if repeating your search with { grep > tempfile } is a bridge too far.

For codebases that use long lines, piping whatever to { cut -c 1 $(tput cols) } can make all the difference.

For dumping text from my mind, I like ed. All of that chrome in visual editors that makes it easy to figure out where you are? That's just distraction for pure input. When done, most languages have language-specific formatting utilities; or, just open in emacs (lisp/emacs seems better than regex/vim for handling syntax) to clean up the visual bits, which can be scripted if you're not looking for the full carpal-tunnel-syndrome experience.

I also like ed for commit messages. Since I perform editing in the terminal, and since ed doesn't clear the terminal view, I can review what I've recently done while writing about what I've recently done. Neat and nifty.

I want to use ed for complex document reviews, too: comparing code, checking multiple sections, etc. For example, create four terminal windows. In three of them, create a FIFO and cat it. In the fourth, open a file in ed -- and write relevant sections to your FIFOs. But the hassle of setting them up, then the mental overhead of tracking which is which has always been too much for me. A someday/maybe project of mine is to write a front-end for ed that handles all of this; basically, a macro editor/launcher, or what emacs started out as but for visual arrangement. Heck, maybe forget the shell and code it into dwm... hmm. A lightweight version of that is [ grep -> ed -> print given lines ], which is similar to folding in other editors.

I've tried tags but never found those systems useful. grep is enough.

A common theme here: the way I use lots of utilities is slow, but it forces me to evaluate similar search results and to remember locations, all of which helps me understand and navigate a project after a bit of exposure.

For non-coding (e.g., fiction), I use the filesystem as an outliner. Use tree to get a listing; edit chapters in chunks, then cat together for review; maintain notes and research documents in another tree then 'ln -s' them where relevant. Backup early and often; plain text makes this easy.

I don't do syntax highlighting. My brain might be different, but all those colors are pretty and pleasing without being informative; they make me think I understand more about the code than I actually do. Coding style is all that's needed to quickly figure out what highlighting is supposed to convey. Again, though, your mind might be different. And there is a 'cat'-like replacement that does syntax highlighting, if slowly ... 'bat', maybe?

But mostly I just use vim, partly because most editing is fixing typos, but also due to the difficulty of slowing down enough to learn to do things quickly.
Received on Sat Feb 12 2022 - 19:42:06 CET

This archive was generated by hypermail 2.3.0 : Sat Feb 12 2022 - 19:48:09 CET