Serving plain text in Geminispace?

=> ================================

I don't know what it is. There is always *something* that I'm

unhappy about when it comes both to Gemtext or HTML (and the Web in

general), and so I always oscillate between them, never really content.

First, I don't like that you can't hard-wrap lines that belong

to a single paragraph in Gemtext. In HTML, you need to make paragraph

and line breaks explicit with and tags, which is tedious. In

LaTeX, it's a bit easier: you don't have to make paragraph breaks

explicit with tags (which are easy to forget anyway); instead, they are

inferred when you leave a blank line. (Line breaks are \ in LaTeX.)

That (i.e. blank lines) is how people have been marking up paragraphs

all the time anyway with typewriters (okay, sometimes tabs have been

used too) and later emails. (Markdown infers paragraph breaks the same

way, but I've always disliked Markdown's way of marking up line breaks

with two spaces at the end of a line. You can't see them without a

special text editor, and I feel like it's so hard to determine when

whitespace at the end of a line has NOT been put there accidentally that

it should just be discarded everywhere it's encountered.) (Groff ms

marks paragraph breaks explicitly with .PP or .LP (and line breaks with

.br usually), but you can't use blank lines at all.)

The big advantage of being able to hard-wrap lines in a

paragraph (as with HTML and LaTeX (and Markdown (and Groff))) is that

you can split a paragraph into smaller units, like sentences or

half-sentences. This makes editing easier: if I want to delete a line in

my favorite editor (GNU nano), I just need to hit ^K and it's gone. Or I

can move it somewhere else (e.g. to rearrange a sentence or paragraph)

by pasting it again with ^U. No re-hitting or holding down Backspace, no

moving to the right spot in the sentence with the arrow keys.

Also, short lines are the natural units of any kind of text

processing on UNIX (or GNU). Let's say you're looking for a sentence (in

the heap of all articles that you've ever written) where you used a

particular word, so you run grep -r. What good does it do you if you're

hit with a single, long line of Gemtext that contains an entire

paragraph? You might try a hack like

grep -ro '.\{0,100\}word.\{0,100\}'	,

but why the hassle? With hard-wrapped lines, you just get the sentence

you need. Maybe add a bit of context with -C, but that's it.

The benefit of Gemtext interpreting every newline as a line (or

paragraph) break is that you can introduce line breaks in the output

without any markup. The obvious use case is poetry. But also if you want

to share with your reader the break-up of a paragraph into semantic

units like half-sentences (which HTML or LaTeX (or Groff) authors would

keep to themselves), you don't need to change a thing. (I've read

somewhere that that's how Churchill used to write down his speeches, and

apparently it also makes sentences easier to parse in some cases, which

is understandable if that's how some authors choose to write their prose

in the first place.) But if you don't want that, if you want to write

your paragraphs in small, semantic units, but have them read in a long,

continuously flowing, justified paragraph, then you just can't do it

with Gemtext.

Then there's the lack of markup inside a paragraph in Gemtext.

You can live comfortably without or \emph{} (or .I in Groff ms, but

I don't like the fact that it forces you to hard-wrap there) if you're

ready to use CAPITALS or asterisks or underscores (and some have

even suggested s p e r r s a t z ). But with inline code, it's a bit

harder. Since text lines in Gemtext are allowed to be rendered in a

non-monospaced font by the specification, you just have to hope that

your code doesn't look too bad when you include it in a paragraph in

Gemtext. (The element of HTML really wins there.) Starting a code

block with ``` lines for every single piece of code that you want to

quote is neither easy to write nor pleasant to read. I've used backticks

to markup inline code in Gemtext sometimes (because no one uses

backticks anyway (rightfully so, I think, because I find them just awful

to look at), except that it's Markdown's markup for inline code already

and it pairs well with Gemtext's ``` lines), but the font problem

remains. Tables in Gemtext are a whole nother issue. (And, unlike HTML,

you can't mark up a switch between languages for screen readers inside a

document in Gemtext.)

The advantages of the Gemini protocol are clear though: TLS

without exception (unlike the Web and Gopher), a simpler and more

privacy-friendly protocol than HTTP, native support for Unicode (unlike

Gopher apparently?), and a smaller userbase than the Web. And Gemtext,

too, has its advantages: no escape sequences, no stupid repetition of

\begin{document}. In essence, it shortens the way between creation and

presentation, between writing and reading (compared to HTML and LaTeX

and Groff, and similar to Markdown). You can just type. (With the

disadvantages mentioned above, of course.)

But what if you take it further? With Gemtext, you still need to

use * instead of - as bullet points if you want them to be recognized by

a client, you still need to obey the single-link-per-line policy, you

still can't use === underlines instead of # to denote headings, you

still can't indent code blocks for clarity if you want to ensure that

people can copy them as-is, etc. etc. What's the shortest way you can go

between creation and presentation, just like writing by hand in the

analog world? It's plain old plain text, one of the greatest inventions

in computing and the prime object and purpose of UNIX's (and GNU's)

powerful tool stack. The freedom you have when writing plain text (and

the lack thereof when writing in other formats) has been nagging my

subconscious for a while now. How come, I thought, I struggle with

writing Gemtext so much, if making ourselves understood in emails is so

easy, even though you have fewer "features" there? Exactly. The

semantics of plain text is clarified by contextual conventions on a

per-document basis. Just like you know that THIS IS EMPHASIS in a

Gemtext document from the context, you know that something is a link, or

a code block, or a poem, or a horizontal rule, or ASCII art, etc. in a

plain text file. In plain text, everything is interpreted from context

alone. It is written by humans for humans, and no one else.

So some of my dissatisfaction can be relieved by switching to

plain text files (at least for writing some articles--complicated

tables still need HTML and some link lists are easier to write and use

in Gemtext). But what protocol should I serve them in? The typical case

would be Gopher, as TXT seems to be to Gopher what Gemtext is to

Geminispace and HTML is to the Web. Gopher's dichotomy of directories

and files, which is claimed to allow for a browsing experience as easy

as browsing files on your local disk, also seems promising. But I have

to admit I don't know enough about Gopher yet, and the Gemini FAQ does

claim to overcome more or less significant shortcomings of Gopher.

(Considering that one of the claims is that UTF-8 content can be clearly

marked as such in Gemini, I'd like to clarify that I'm using ASCII

instead of Unicode here just for the fun of it.) So for the time being,

the following tip from the Gemini FAQ seems like a viable solution:

Of course, if you really like the Gopher way, nothing in Gemini

stops you from duplicating it. You can serve item type 0 content

with a MIME type of text/plain, and you can write text/gemini

documents where every single line is a link line, replicating

the look and feel of a RFC1436-fearing Gopher menu without that

pesky non-standard i item type.

(gemini://gemini.circumlunar.space/docs/faq.gmi)

Anyway, let's see how long I'll stick to that, if at all.

Written after midnight on 2023-02-02

EOF