Comment by 🚀 sy

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

@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.

=> 🚀 sy

Jan 08 · 11 days ago

2 Later Comments ↓

=> 🛰️ 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