Comment by 👻 mediocregopher

=> Re: "More questions on gemtext parsing" | In: s/Gemini

@sy that excerpt reads to me like LF is acceptable for subtypes of text, and explicitly says that gemtext is a subtype of text, therefore LF is acceptable for gemtext.

=> 👻 mediocregopher [.com]

Jan 08 · 11 days ago

6 Later Comments ↓

=> 🚀 sy · Jan 08 at 08:40:

@mediocregopher: I actually had excerpts from the ABNF definition below it, but couln't submit a comment that long, and trimmed:

text-line        = *(WSP / VCHAR) CRLF
; CRLF          from [STD68]

With the formal ABNF, I read it as: without CR it is not (strict/canonical) gemtext but a mere text subtype that can be sent via the Gemini network protocol.

=> 🕹️ skyjake [mod...] · Jan 08 at 08:44:

@sy You can submit longer comments as drafts, or by editing and appending more text, or by merging multiple consecutive comments together.

The BNF is inaccurate there, or shall we say the "canonical" form is not exactly the one used in the wild. Gemtext does not require CRLF line endings. As the beginning of the document states, both LF and CRLF are acceptable and should be handled gracefully by the parser.

IIRC, @solderpunk made some remarks about the canonical CRLF usage somewhere, perhaps in the Project Gemini official news feed. However, I don't think there are many people that specifically choose to use CRLF line endings when they write some .gmi files.

=> 🚀 stack · Jan 08 at 13:38:

As usual, every platform just had to do it in a different way:

Unix: newline

Apple: cr

Microsoft: both

The Unix way is of course the right way.

To make it worse, the tty can and often does substitute one for the other, both on input and output.

=> 🚀 sy · Jan 08 at 14:40:

@skyjake Gemini news talks about empty documents and documents that lack a new line on the last line, and has this:

clarified that Gemtext is specified in its "canonical form" (and therefore uses CRLF everywhere).

=> — geminiprotocol.net/news/2024_08_28.gmi

And the wire protocol has this:

When in canonical form, media subtypes of the "text" type use CRLF as the text line break. Gemini relaxes this requirement and allows the transport of text media with plain LF alone (but NOT a plain CR alone) representing a line break when it is done consistently for an entire response body. Gemini clients MUST accept CRLF and bare LF as being representative of a line break in text media received via Gemini.

=> — geminiprotocol.net/docs/protocol-specification.gmi

Reading the document and wire specifications together, I would understand that rather than stripping the CR, a network client should add the CR if it doesn’t exist on the wire :)

As for actual answer on questions by @lufte: I would suggest that, if you cannot unambiguously ‘fix’ the inconsistencies when parsing, you can always output the line as is, as ordinary text.

=> 🛰️ lufte [OP] · Jan 08 at 15:26:

@mediocregopher I like your interpretation: if any subtype of text (text/gemini being one) can be transmitted with line breaks represented by LF alone, then it means they should be parsed as line breaks as well and not be just merely "transmitted".

The excerpts of the network protocol provided by @sy also support this interpretation.

As for "=>\n" lines, defaulting to text may be the most sensible choice.

=> 🚀 stack · Jan 08 at 16:20:

I am willing to publically shame those not using Linux or maybe BSD! Or ignore their backwards propriatary ways.

Original Post

=> 🌒 s/Gemini

More questions on gemtext parsing — I'm rewriting my gemtext parser and I've landed on questions that I decided to ignore the first time around, but now I really want to solve: 1. All lines beginning with the two characters "=>" are link lines, says the spec, but also is mandatory, so how do we handle a line that is simply "=>\r\n"? 2. What if is not a valid URL or it doesn't have reserved characters encoded? 3. Should single '\n' and '\r' characters be ignored, replaced by a...

=> 💬 lufte · 12 comments · Jan 08 · 12 days ago