Gemtext can be worse than plain text
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: plain text files.
Plain text 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 plain text?
How did plain text 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 plain text. 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 plain text 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 plain text 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 plain text emails. == Email Style 2 == It Eventually Inspired Markdown There's plain text 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.
* Plain text is limited only by your hardware.
* Plain text, 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 plain text, 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 plain text 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 plain text. 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. Plain text 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 plain text. 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 plain text.
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 plain text. 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 plain text.
Going forward, I'll consider experimenting with making my posts in plain text. There's not much to lose. But I really do like providing links for context. I think plain text 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 plain text.
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/