what gemtext is and isn't
september 18, 2020
I'd like to update this gemlog more regularly, but I've been tending towards longer, high quality(?) posts over regular, shorter posts. I actually have two work-in-progress gemlog posts and a project that I'm working on and I was hoping to have one done and ready to post today. Well, that didn't work out because they all turned out taking way longer than expected, but I haven't posted in a while so I'm writing a (relatively) short post here.
There was an argument going on in the gemini mailing list a few days ago that started with ~~abusing~~ **using** the "alt text" in preformatted blocks like they are used in markdown, to trigger stuff like syntax highlighting. It turned into general complaints about gemtext as a whole, and the main thing I learned is that most people want gemtext to be html, just without the "bad parts" (and javascript is the *only* agreed-upon "bad part"). The problem with that is that gemtext isn't even meant to be a markup language at all. The long and short is that gemtext is a gophermap with real support for text & preformatted blocks, and better linking. That's it. The fact that it has stylistic niceties like headers or bullet points is purely incidental because they're easy to implement. The fact that gemtext isn't a markup language at all is mitigated by the fact that you can link to *literally* any file type. People in gopherspace make do with no formatting other than links and then linking to a very limited number of filetypes, and in fact, isn't that why so many people love gopher in the first place?
Even though the gemini spec isn't technically finalized yet, no significant modifications or extensions to gemtext or the spec as a whole should be made. A "living standard" is not a good thing, all it does is make it impossible to have a client or server that's isn't a full-time job to maintain. The fact that not only do people want to change the spec, they want to change gemtext into an ad-hoc, impossible-to-parse implementation of half of html, one of the worst changes you could ever propose.
I believe most people didn't like these proposals to change gemtext, but some people did suggest that a new richer format be made as an alternate for or to supplement gemtext. While I understand the desire to make something new and custom for your use[1], it is almost always the case that someone has your same needs and wrote something that's does what you need. The whole point of having mimetypes in gemini is so you can use whatever format you want to serve content. If you want basic linking and sectioning, use gemtext. If you want rich formatting (emphasis, boldface, etc) use markdown or asciidoc or any of a million lightweight markup languages. If you want deep control over the presentation of the document, use html. If you want no formatting at all, use plaintext. There's near certainty that there's an existing format that generally suits your needs unless you're doing something like math formulae, and even then you could just link to an image or use a pdf and LaTeX. Reinventing the wheel doesn't help anybody[2], I already get confused between vimwiki markup, mediawiki syntax, and markdown, I don't want to learn yet another markup language.
Basically, what I'm trying to say is that gemini gives you the greatest freedom ever to use whatever file formats you want for your content, and people get stuck thinking they absolutely have to use gemtext, and then start complaining about the "limitations" of gemtext while completely missing the point that those limitations are deliberate. It definitely seems like bikeshedding[3], because no one talks about whether TLS 1.2 should be allowed, or if there should be a response body terminator for clients to check that the full page was transferred.