On Fri, Feb 11, 2022 at 3:47 AM, Daniel Littlewood <danielittlew...@gmail.com>
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.
