=> Re: "More questions on gemtext parsing" | In: s/Gemini
@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.
Jan 08 · 11 days ago
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.
@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.
I am willing to publically shame those not using Linux or maybe BSD! Or ignore their backwards propriatary ways.
=> 🌒 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 This content has been proxied by September (ba2dc).Proxy Information
text/gemini; charset=utf-8