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
