💾 Archived View for thrig.me › blog › 2023 › 05 › 15 › ex-over-ed.gmi captured on 2023-06-14 at 14:02:50. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-05-24)
-=-=-=-=-=-=-
gemini://sotiris.papatheodorou.xyz/gemlog/20230514_meditation_on_ed.gmi
ex(1) has several advantages over ed(1), notably the ability to run filters, and can switch over to vi(1) via the ":vi" command if you get in over your head. Switching to a visual editor might be cheating if the goal is to learn a line editor properly.
/blog/2022/11/26/vi-exit-strategies.gmi
There are differences between ed and ex, and unportabilities between various implementations of ed; the notes here concern OpenBSD's ed and ex which may vary from GNU/ed and the other editors that pretend to be ex these days. Check the fine manual for details.
ed punishes distractions; in a visual editor it is quite easy to wander all over the place, maybe to put in a closing line first, then to go here, and maybe there. This is more difficult in ed as you then have to worry about clobbering that line for the rest of the session; it is easy to forget about some line you haven't seen for a while and wipe it out, especially if the line is floating right below where you are editing. There are techniques to avoid this; you might write to various files and then use cat(1) to rejoin them. Still, this is an improvement over a typewriter where the text is largely write-only. In that case for a long document you might need a plan, an outline, maybe a series of index cards to work through, and hopefully not too many re-writes.
Anyways, particular differences between ed and ex involve how to show a range of numbered lines; in ed one might use "1,$n" while in ex that might be "%nu" for "number" as "n" is instead the "next file" command. These commands can be highly irregular; look at the comments under the source of vi on OpenBSD for such details. This is also a good way to learn about ex commands you may have never seen before. Probably it was Bach who said one might start to understand music after 20 years or so; an editor may take a similar amount of time to get through most of the nooks and crannies. (Patience, how long will that take?)
ed as stated above lacks filters; the most one can do is "r" to read in a file after the addressed line. For example if you had some command line example, as these postings almost always do, ... err, well, that totally did not work out, and now I'm trying to recover. "-5,.p" will show the context of the last five lines, which in ex is the shorter sequence "-5,p", as one may omit the "current line" from the range. Another handy command sequence is "a...-1,.j", which allows one to produce various sentences and then join them up into a paragraph. Note that this may need to be done backwards: a line number listing will become increasingly inaccurate if you do the edits from the top down. The s/.../... command is handy for little touch-ups, perhaps you typed "THe" instead of "The", things like that.
With these mild details mostly done being tripped over, now to a filter example. One might have some mangled code,
static int
check_addr_range(int n, int m)
{
if (addr_cnt == 0) {
first_addr = n;
second_addr = m;
}
if (first_addr > second_addr || 1 > first_addr ||
second_addr > addr_last) {
seterrmsg("invalid address");
return ERR;
}
return 0;
}
which in ex one could reformat in-place with maybe "1;/^`/+1" to get to the first line of the code block, then ",/^`/-1!clang-format" to filter the lines. ed has no such feature; one would have to extract the text to a file, delete the lines, format the file to a new file, then read that new file back into the right place, so maybe:
1;/^`/+1
.,/^`/-1w f
.,/^`/-1d
!clang-format f > g
-1r g
which is pretty awkward compared to an ex filter. And I got it wrong, lots. This is probably why ex added support for filters. Also ed lacks support for > and < so there's no way to indent code blocks. I should say, no easy way; ".,/^`/-1s/^/ /" could be used, but that's more to type. The "/^`/" regular expression is looking (poorly) for gemini ``` preformatted toggle lines. More correctly one would search for "/^```/" but that's also longer to type.
(As a simpler example, consider sorting all the lines in a file. With ex, that is "%!sort" while in ed it would be simpler to "wq" and then from the shell run "sort yourfile > x; mv x yourfile; ed yourfile". Filters are pretty swell, and eventually the sed implementations out there copied the -i flag from Perl.)
Maybe you want to preview the disaster in the making; both ed and ex support the "!" bang command, though in ed there is no autowrite so you'll need to remember to save the file first.
w
!amfora %
vi has the advantage here of maps, where you can specify that "\t" (for "try it out") saves the file and then opens it with amfora. This is much less typing. Another option might be to use entr(1) or similar to react to file changes; this way one could arrange
$ echo blog-about.HQjs2nswvd.gmi | entr amfora blog-about.HQjs2nswvd.gmi
...
in another terminal, which then would launch amfora on this file every time it is saved. The awkward filename is because a temporary file is created that eventually gets shoved into a sqlite database. There are certainly other ways to do this sort of thing, but I went with a little sqlite db.
$ VISUAL=ed blog-about ex-over-ed
a
...
There were some vi-isms in the blog-about script that I have corrected; not all editors (and not ed in particular) support the "+linenumber" syntax to change to a different line when the file is opened. This might be something nice to standardize on in some future operating system so you don't have to guess from the editor name what options if any support changing the line the editor opens at.
my $editor = $ENV{VISUAL} // $ENV{EDITOR} // 'ed';
The above was inserted by way of "r !grep VISUAL `which blog-about`". You'll find code that only checks for EDITOR, though a correct implementation is supposed to use VISUAL if one is in an environment that supports that (as most terminals do, these days) and only then falling back to EDITOR, and only then to ed. Non-visual environments would presumably not set VISUAL so that EDITOR and then ed would be used.
Keeping notes is proving very handy: make a list of changes as one reviews the document, close the preview, and work through the list of changes. Plus another list of topics to touch on; this list reminds me to note that ed only supports basic regular expressions. Basic re are probably a bit too minimal these days.
http://man.openbsd.org/man7/re_format.7#BASIC_REGULAR_EXPRESSIONS
For a more advanced challenge, you might write your own implementation of ed and use whatever fancy regular expression engine you like. Modern regular expressions are not, strictly, regular expressions, but we still call them that. So language evolves.
The best takeaway here is probably to minimize distractions and interruptions. Reduce context switching; if you have an idea, stick it in a notebook and forget about it, and go back to what you were doing. Maybe try to better separate the editing or creative phase from the critic and review phase. ed certainly helps with this, as not all the text is always there to distract you.
I'm pretty sure some unix titan had a snappy "why would I want to look at what I had written?" line, but le search engines are not helping me find the quote. Okay Sotiris found it, thanks Soltiris!
By the way, 'em' stands for 'editor for mortals' - I christened it that after Ken Thompson visited our lab at QMC while I was developing it and said something like: "yeah, I've seen editors like that, but I don't feel a need for them, I don't want to see the state of the file when I'm editing".
https://www.coulouris.net/cs_history/em_story/index.html
So it was "some unix titan" or the other.
tags #ed #ex #vi