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! ::-::
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
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 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).
.:.