(This is part of a "what if" series of idle thoughts. If you haven't read the introduction, please do that first.)

Line Mode Markers

Background

In my interpretation, the gemini specification contains three different categories of markup:

Start-of-line markup, such as for making links, bulleted lists, and so on.

Full-line markup, which is only used for toggling preformatted text mode on or off.

Absence of markup, for normal or preformatted text lines. (Maybe you don't consider this markup at all, but I find it useful to consider it separately from the other categories.)

The gemini specification, of course, doesn't make these distinctions explicit, but this is how I organize them in my mind.

The topic of this page is the second category, full-line markup. Currently (and probably forever), gemini only defines one element in this category: the triple-backtick (```) which marks the beginning and, later, the end of a preformatted text block.

I call this category "full-line markup" because, unlike the other categories, nothing on the line is required to be displayed to the user. The entire line is "consumed" by the markup. Any text that follows the triple-backtick at the beginning of a preformatted text block may be treated as alt text that describes the content of the block, but this is not required.

Preformatted text lines are treated differently than normal text lines. They should be displayed in a monowidth font, without any wrapping of long lines.

Now the background is out of the way and I can get to the premise of this essay.

What are line mode markers?

Instead of using a single markup unit (the triple-backtick) to toggle preformatted text on and then off again, I would suggest using a two different symbols. For example:

``` to enter preformatted mode

,,, to enter normal text mode

I will call these "line mode markers", since they change how the parser should display any following lines.

Like the current triple-backtick syntax, any text on the same line as a line mode marker may be ignored by the parser, or else treated as alt text or contextual information.

If the parser encounters one of these line mode markers while it's already in the specified mode, the line should have no effect on the rendered content.

Why does it matter?

At first glance, this doesn't look much different than replacing a "toggle preformatted mode" syntax with separate "open preformatted mode" and "close preformatted mode" syntaxes. However, the important difference is that each line mode marker is related to the lines after it, never the lines before it. This opens up some interesting implications.

First, we unlock the ability to annotate all kinds of text in the same way that the alt text can annotate a preformatted text block. The best example is that we could specify the language of specific paragraphs to be different than the surrounding text. It's currently impossible to clearly mix languages like this in gemini.

Second, I would go ahead and extend this to include a third mode:

>>> (or """ ?) to enter quote mode (replacing the current start-of-line syntax, I guess)

This quote mode differs from the current quote syntax in that it could allow start-of-line syntax within quotes! Currently, if you want to quote a gemini document, you can't include any links within that document without dropping out of the quote. This makes quote mode more powerful.

Third, I think this creates an elegant parallel with the start-of-line markup syntax. You never "close" your link or bullet markup in gemini the way you do in HTML. You just move on to the next line. Similarly in this case, you no longer "close" preformatted text mode, you just start a new mode and leave the old mode behind.

Okay, but it doesn't belong in gemini

Yeah, I understand.

First, it would break any documents that use the existing specification for preformatted text. Instead of toggling off preformatted mode, a second set of triple-backticks would essentially be ignored and the document would continue in preformatted mode. Since gemini encourages long, single lines of text (that can be wrapped by the client), these would be badly broken if displayed in preformatted mode.

Second, it raises difficult questions about what exactly it means when there is text on the same line as a line mode marker. For preformatted sections, it makes sense to use alt-text, since the content might be ASCII art, or a diagram, or some other graphical content that doesn't can't be easily interpreted by a screen reader. For normal text mode, however, an alt text description isn't really necessary. Maybe there are some situations where it could help a screen reader to describe the upcoming section, as with a "Navigation" section that contains repetitive links that the user might prefer to skip over. My proposal above was to use this text to indicate the language of the following text, but now things are confusing. When does an advanced parser know whether the text indicates a language code, or alt text, or something else entirely?

Of course, we might define a specification that allows both language and alt text to be used in any section marker. Like HTML, we could set properties as in "lang=fr, alt=whatever". But that road leads to extensibility, which gemini has worked so hard to avoid. And, from a strictly aesthetic perspective, it reduces the "natural" readability of the source code.

Third, if we accept the addition of a quote line mode, then the old quote syntax becomes redundant and should probably be removed. This introduces more backwards incompatibility.

emptyhallway

2020-09-02