Updated Thoughts On Gemini
Previously I had written about my experiments with getting Gemini to be used for different cases. Having now used it for a while, I'd like to reflect on what has and hasn't worked.
Gemtext is more than glue
I previously stated that I wanted gemtext to be used more like a glue to bind content together. I saw how well this worked for Gopher, and wanted Gemini to be that with more power.
A lot of people disagree. They find the experience of switching between clients much more disruptive than I do. They want to experience everything from within the same client for their full browsing experience. The only way to do that is to use gemtext or plaintext.
The vast majority of people are using Gemtext. Almost no one is uploading other filetypes. For formatted content, PDF seems to be in the lead. Lilypond surprisingly has more use than Markdown.
Unfortunately, platforms such as flounder.online do not even allow text files with different extensions. No Markdown, latex, LillyPond, etc. It restricts to just Gemtext (gmi) and plaintext (txt).
I can understand not allowing other formats like PDFs, html, video, etc. That could quickly raise the storage costs of hosting. But it leaves user's only other formatting options to be a couple image formats.
I was hoping to find a Gemini hosting site that would allow me to host other formats. My formatted example links in the previous Gemini post are still broken because I have not been able to find hosting that does not rely on HTTP services. As an ecosystem, Gemini lacks file hosting, so we are stuck with gemtext.
The protocol technically can handle it sure, but there's no support for it. Requiring people to self-host to do so is not a good long-term strategy. Providing necessary features in the gemtext format will further expand Gemini's usability by allowing everyone to discuss using the same chosen format.
Gemtext needs to be more than glue. And that means giving it the features necessary to support a community.
New Tactics
I previously wrote about how gemtext can be worse than plaintext. Since, I've been thinking of how to help make gemtext better than it, or at least bring it up to parity.
Gemtext Can Be Worse Than Plaintext
Inline formatting
If inline formatting should be included or not has probably been the most heated topic of Gemini.
There's two camps: Pre-rendered vs Semantic formatting.
Pre-rendered means the text is formatted and set at the time of the document's creation. It's very static. Prone to breaking if the client can't render it. Does not interface well with screen-readers.
Semantic formatting uses formatting markers to signal to the client how to render the document. All formatting is done client side, which gives the application more information on how to interpret it. The user is also given preference on how to display it.
I advocate for the semantic formatting side. But since we don't get any, we are stuck with pre-rendered.
I hope I made it clear in my previous post that pre-rendered text is not a good solution, but it is *a* solution. And currently it is the only *real* solution. People are going to continue using it until a better solution becomes available.
There is also a small group who believe that no formatting at all is the way to go. These people are not writers. They don't understand what functionality basic typographical features such as bold and italics offer and insist they are worthless. I say they are free to write in whatever style they want, but they should not be forcing it on others.
Wikipedia's section on usage for italic type
Wikipedia's article on emphasis
These people can be easily appeased by having a client that can simply ignore inline formatting. Bold and italic text instead get rendered the same as the rest of the body text. This way it is up to the user if they wish to ignore semantically important elements. This is only possible to do when there is a formatting markup. It can't be done with pre-formatted elements.
They must be the kind of people who also prefer that spoken word be entirely monotone, because that is the type of text they are advocating for. The people advocating for "quiet text" must be horribly overwhelmed by print media.
Go old school
Some alternative approaches I've seen are to use the old school plain text markups we used to use in plain text emails or when talking on forums. The kinds of things we used to use before Markdown came to dominate.
– //italics//
– *emphasis*
– **bold/strong emphasis**
– _underline_
– ~~strikethrough~~
– ^^superscript^^
– __subscript__
– `preformatted`
– ++highlight++
– <thought-speak>
– etc…
We can go back to doing this. People will generally understand what is meant by the basic ones. Perhaps if we're lucky and the feature gets added, we won't even need to update our writing.
One possible issue with this is that it is more personalized. Different communities are going to come up with their own ways of marking these, which can lead to confusion.
For now, it seems most people pretend the Markdown formatting still exists. But Markdown is very inconsistent, almost intentionally, so which version of Markdown should you go with? Who knows.
It would be better to have a standardized agreement built into gemtext, but sadly, this is not likely to every happen.
SHOUT IT OUT
Another way to add EMPHASIS to text is to make it ALL CAPS.
It should be used sparingly though, since it is often read as yelling. But it is one of the few dynamics we currently have access to, so use it wisely.
Codeblocks already break the rules
Gemtext was (supposedly) designed to have one formatting element per line. Every line can be parsed in isolation by looking at the starting characters of a line.
The specs have this to say:
5.3 Line-orientation
As mentioned, the text/gemini format is line-oriented. Each line of a text/gemini document has a single "line type". It is possible to unambiguously determine a line's type purely by inspecting its first three characters. […]
Codeblocks break that by introducing one element across multiple lines. Clients can no longer render formatting by looking at lines in isolation. They cannot look at the first three characters of a line to determine its type. (5.4.3 Preformatting toggle lines)
It's further complicated by how opening preformatting lines can contain alt-text, while the closing preformatting lines can't. It's two elements in a line: preformatted text toggle, and alt-text.
You'd be better off implementing a PEG parser, or you could get away with an LL parser. This means inline formatting, if chosen carefully, would not be any more challenging to format, as is claimed.
https://en.wikipedia.org/wiki/Parsing_expression_grammar?useskin=vector
https://en.wikipedia.org/wiki/LL_parser?useskin=vector
Lists
The gemtext standard does not provide bulleted lists past 1 depth. This limitation feels silly because it makes gemtext worse than plaintext at this.
In plaintext, if we want bulleted lists, we could simply add them.
* One
* Two
* Three
Gemini clients seem to strips away any left-side spacing in gemtext, giving us no control.
- One
* Two
* Three
This is true even when not using any formatting marks.
One
Two
Three
This choice was likely more to do with it being more challenging to parse than any other reason. (Though this does not break any rules that code blocks do not already.) This is Markdown's approach to bulleted lists, and Markdown is known for being challenging to parse. It makes me wonder why it was chosen as the base to reference the syntax from.
I suggest allowing bulleted lists with the same depth as headers are (depth of 3), with a similar syntax. The number of asterisks a line starts with is the depth of that list element. This follows the rule of having 1 element per line and is easier to parse than Markdown's.
* One ** Two *** Three
If you are worried this could be abused by having someone start at an indentation other than 1; let them. Solve that problem for headings first. It's not harmful if someones list doesn't start at level 1. This is a strength. Suppose the user wants to focus on a subsection of a bigger list. Preserving the level will improve clarity.
List workaround
Until such a feature is added, we are left to use workarounds.
I've tested that the following workaround works in Amfora, Astro, AV-98, Buran, Deedum, Fossil, Lagrange (desktop and mobile), as well as through portal.mozz.us/gemini.
To do this, use anything other than an * to bullet a list. I suggest an en-dash (–). Then to force preserving spacing, use a /figure space/ character for indentation. I suggest two spaces for each level of indentation. That leaves us with this:
– Look
– Ma!
– No
– Conformity!
This brings us closer to the same level of control as we would have with plaintext. Additionally, we are not restricted to using the same style for each indentation.
• You could use a bullet, like usual.
‣ A pointy.
▪ Whatever you want!
Because of this, we can also have indented enumerated lists. Here is a more complete example.
~~~~
The structure of a turn in Magic the Gathering is as follows:
1. Beginning Phase
a. Untap Step
b. Upkeep Step
c. Draw Step
2. Precombat Main Phase
3. Combat Phase
a. Beginning of Combat Step
b. Declare Attackers Step
c. Declare Blockers Step
d. Combat Damage Step
e. End of Combat Step
4. Postcombat Main Phase
5. Ending Phase
a. Ending Step
b. Cleanup Step
~~~~
The best part about this workaround is that we are using the UTF-8 character as intended: a space. No one can reasonably complain about this use like when using mathematical characters to represent bold text.
This issue could be fixed in gemtext by simply not stripping whitespace. Let users define their spaces. I'm not sure why clients do it in the first place, since there doesn't seem to be any mention to do this in the specs. It seems more to be a leftover from Markdown.
Then, do we really need lists to be a special feature? As they currently are, they don't do much. You'd get the same effect as using - to mark a list as you would with *.
Remove both whitespace stripping and lists and you bring back the same level of power as plaintext, while further simplifying work for developers.
Code block lists
A more conformist way to include multi-level lists is the same as before: just use plaintext. Gemtext (sort of) allows us to embed plaintext through code blocks. Format the list however you want and surround it in graves (```).
This is abusing code blocks yet again. Code blocks are disruptive to the flow of content and do not look good. But they are less likely to break since it's not outside the spec.
Math forumulas
DJ Chase has demonstrated an impressively effective method for displaying math formulas in gemtext while maintaining accessibility.
//dj-chase.com/documents/re-sub-sup-gemtext.gmi
Summarized list of suggestions for gemtext
– Add inline formatting. (Sacrilege, I know.)
– Do not strip whitespace.
– Fix lists by either:
– Adding multi-level list syntax where depth is equal to the number of * at the start of the line.
– Removing lists entirely and not stripping whitespace.
/gemlog/