more, troff&co, ed&co, FIFO&TTY

   This is why I like to use more (not just for the fact it does not
   change to the alternate display, therefore keeping in the terminal what
   I just finished to read):
--More-- (102% of 2654 bytes)

   It gives you even more for the same amount of data! ::-::
     __________________________________________________________________

   [1]sparcipx and others have brought up the topic of troff to which I'd
   count also the variants groff (GNU's version) and nroff (the pure ASCII
   version, IIRC).

   Don't forget its companions, the gems eqn , tab and pic !

   I wouldn't be able to use them by heart, but there was a time I mostly
   worked with them -- more or less right after I wrote my PhD thesis with
   LaTeX and my diploma thesis with TeX. I liked much more the line
   structure of *roff and company, instead of the awkward "backslashitude"
   of *TeX.

   However, in the context of writing content and not form, I much prefer
   Markdown, because it focuses on the function, like HTML before people
   began to torture it into a page design language. (Don't get me started
   on the horrors of receiving HTML formatted e-mails of 3 kB content
   wrapped in 300 kB of formatting garbage.)

   Therefore, although I really love the *roff philosophy, I don't really
   see a good use case for it in the gopher context. Unless one is
   interested in creating graphically appealing pages, which is out of my
   league, I admit!

   My phlog/glog/blog currently is handled through [2]plog, which passes
   text through Markdown and then lynx to generate the text- only version
   for gopher. However, I'm currently thinking about putting the
   markdown-formatted text directly into the gopherhole, as it may even
   look better (except for the automatic filling of paragraphs done by
   lynx, which of course could also be handled by fmt or fold or the
   like).
     __________________________________________________________________

   Last week I tried to write an ed wrapper, inspired by edbrowse. The
   idea: have a shell script which launches ed through a FIFO, and then
   transparently passes ed commands, or sequences of commands for
   predefined macros. This way, one would not need to reimplement ed as
   with edbrowse, but could build on the ed already present on the target
   system. Because the aim was to have a wrapper for ed and dc, the script
   is called [3]edcsh.

   However, not all systems are made equal, unfortunately: the script so
   far works acceptably well on my laptop with Ubuntu, on my work machine
   with OpenBSD, and on Android with Termux, but not on my old PowerPC
   iMac (Darwin). Apparently that ed version stops whenever an error is
   raised and the input is not a terminal! Belgium!

   I don't know how to handle this, for the time being. I doubt a portable
   method exists to fully simulate a TTY through a pipe, and I don't want
   to rely on socat and company.

   So there, might be a dead end.
     __________________________________________________________________

   By the way, the OpenBSD experiment on the Acer ASPIRE ONE is still on
   hold; did not have the time to work on it!

   But I got bitmessage working again on my OSX10.7 MacMini and on my
   Ubuntu laptop, after the recent severe vulnerability (which nobody ever
   reading this might care about, sure).

   .:.

References

   1. gopher://sdf.org/0/users/sparcipx/phlog/March_2018/03-09-18
   2. https://github.com/hb9kns/plog
   3. https://github.com/hb9kns/edcsh