Gemtext can be worse than plaintext
Recently I was thinking about the limitations of gemtext, and how to work around those. For inspiration, I started thinking about how those issues were handled in other limited formats. I thought back to what's often considered the most limited format: plaintext files.
Plaintext is limiting because it has no formatting at all. There are no semantic elements. That's also part of it's strength, allowing it the most universal support.
Comparing gemtext to other, intentionally more advanced markup languages would not be a fair comparison. But what about a step down to plaintext?
How did plaintext users work around the same kinds of limitations gemtext has? Well, turns out… they didn't have many.
That's right. Gemtext is more limited than plaintext. But how can that be? Gemtext has *features!* It's a stripped down Markdown, right?
Well, it does, but they come at a cost that ends up limiting it in unexpected ways. Gemtext imposes new limitation in order to enforce the features it adds. The main thing being that in gemtext, our control over whitespace is stripped away from us (literally). This greatly limits what we're allowed to do with our text in each formatting block.
Let's take a look comparing the different ways each format handles things.
Paragraphs? Easy.
Gemtext enforces that lines should not be hard wrapped. This is great because soft wrapping ensures it wraps nicely on any monitor size. Authors using plaintext often feel the need to make the line wrapping themselves. But any modern text reader should have the ability to soft wrap lines now. Even nano supports it (Esc, then $, or Alt+Shift-$)..
Basically anything can make paragraphs, so that's not saying much.
But, unlike gemtext, you can choose your paragraph style. You could use indented paragraphs like in traditional printing, or a more modern double-spaced paragraph layout. However, this paragraph may not display correctly in a gemtext code block since code is indented all together. Depends on how your client chooses to render it.
Headings? Sure, your Gemini client might style your headings for you, but you're limited to three. In plaintext you're only limited by your imagination.
This is a classic heading ========================= It's also valid Markdown. ========================== | I like to cap the ends | ========================== And place the boarder on both sides. ----------------------------- This is a lower level heading ----------------------------- Again, Markdown. ############# More headings ############# Now we're getting into reStructuredText. ************************ Could this be a chapter? ************************ """""""""""""""""" Here's another one """""""""""""""""" ~~~~~~~~~~~~~~~~~~~~~ Now we're freestyling ~~~~~~~~~~~~~~~~~~~~~ ! WARNING: THIS COULD BE A SUBHEADER ! [ I used to use this method in college ] = Email Style = This used to be a way to format headers in plaintext emails. == Email Style 2 == It Eventually Inspired Markdown There's plaintext wizards out there who could make some really impressive stuff. The basics like this are enough for me.
How about lists?
- Gemini is limited to a depth of 1.
* Plaintext is limited only by your hardware.
* Plaintext, however
* Can go as far as you'd like.
* (Warning: Other people may not like.)
– You can use more than bullets.
• Stylize depth to distinguish more.
▪ Any text character is valid.
1. Enumeration?
2. No problem!
a. Can even change it up as we go.
i. How about Roman Numerals?
ii. I don't actually like them.
How about block-quotes? Gemtext block-quotes are actually quite cumbersome to apply, having to go through each line and add "> " to each. (Check if your text editor has a multi-cursor mode to make this easier.) Plus, they don't handle attribution correctly, since proceeding whitespace is stripped.
Once upon a midnight dreary, while I pondered, weak and weary,
Over many a quaint and curious volume of forgotten lore—
While I nodded, nearly napping, suddenly there came a tapping,
As of some one gently rapping, rapping at my chamber door.
“’Tis some visitor,” I muttered, “tapping at my chamber door—
Only this and nothing more.”
— "The Raven", by Edgar Allen Poe
In plaintext, you can simply indent some text aside to show it's not part of the main body.
Note that the original text's indentation is not lost like in gemtext. (They are formatted identically.)
Once upon a midnight dreary, while I pondered, weak and weary, Over many a quaint and curious volume of forgotten lore— While I nodded, nearly napping, suddenly there came a tapping, As of some one gently rapping, rapping at my chamber door. “’Tis some visitor,” I muttered, “tapping at my chamber door— Only this and nothing more.” — "The Raven", by Edgar Allen Poe
Codeblocks? Markdown has shown that for code, all we need to do is indent it. Yes, this is similar to quotes, but as people reading it, we can identify that context.
Here we have the heart of the most advanced program ever to be written in C. Prepare yourself!
#include <stdio.h>
int main() {
printf("Hello, World!");
return 0;
}
Such sophistication is a level us mere mortals can only hope to achieve after a lifetime of dedication. Study it, and you may one day unlock its great mysteries.
URLs? There's probably some text readers out there that let you click urls, but they're not common. (Lynx?) Gemtext ensures any Gemini client can click the links.
Linking is a feature of nearly every markup language. This brings it in line with gopher menus.
There was sort of a standard for plaintext email clients to recognize urls wrapped in <> to be links, but I don't think it caught on much.
Ask your your parent's permission before going online. <https://www.pbskids.org>
Image embedding? Eh, gemtext kind of can do this if the client supports it. Client developers are not supposed to fetch these automatically, since it would be multiple server requests. Users are required to click on it to open it.
Lagrange handles this nicely by allowing a linked image to display inline. Can't really do that in plaintext. There's clients that do it, but they're not common or expected. I'll give gemtext half a point for this, since it's a client feature rather than language feature.
That leaves gemtext's strength being that you can click urls, and sometimes they're images. I'll give it that. So it wins 1.5 out of 6ish features? That's not a good score. And this is just comparing feature parity between the two. Plaintext can offer a lot more on top of that.
A table of contents. Footnotes. Endnotes. Section breaks. Freeflowing stanzas. Lyrics. Sidebars. Indented paragraphs. And more.
I sometimes see gemtext compared to gopher menus. But within their respective communities, they serve much different purposes. Most content pages on gopher are in plaintext. Gopher menus link them together.
Gemtext is used both for linking and as content. Being able to create links within content is nice, but there's a trade-off that now the content is far more limited than what could be done with plaintext.
By comparison, even though Markdown does a similar level of stripping, it could be argued that it adds more than it takes away. Inline formatting means you can apply emphasis to text, which can't really be done in plaintext. There's hyperlinks. Self formatting tables. Images can be embedded. All features gemtext neglects.
The whitespace stripping is to aid it's presentation in it's target format, HTML. It doesn't make sense to keep that feature in gemtext, where it could be basically an enhanced plaintext.
Going forward, I'll consider experimenting with making my posts in plaintext. There's not much to lose. But I really do like providing links for context. I think plaintext will be a better choice for standalone writing.
People have been talking about gemtext's "purpose" as if that's clearly defined by the specs. Purpose is defined retro-actively as a result of ability and role. I personally would have liked if it was a more lenient alternative to gopher menus, but that hasn't been the case. People are using gemtext for content itself.
I'm looking at gemtext purely by its feature set. The features available are what determine what it's good for. It's okay for linking together content. It's bad at pretty much anything else, by comparison to plaintext.
An example of a text file with some advanced formatting on Gopher.
gopher://0x1bi.net/0/textfiles/file?sf/STARTREK/trek_gde.txt
The Gemini specification does not specify that clients should strip whitespace. I encourage client authors to not do it. If a line starts with any amount of whitespace and is not inside a preformatted block, treat it as a text line.
//gemini.circumlunar.space/docs/specification.gmi
It advises *against* collapsing vertical whitespace (newlines). Please follow the same for horizontal whitespace.
/gemlog/