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

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