Before removing "inline" code support from the ggemtext library,
I would like to request an additional review from the community regarding this issue:
gemini://bbs.geminispace.org/s/Bubble-Issues/140
Does Gemtext format really not support closing a pre-formatted tag on the same line where it begins?
2025-03-21 · 1 year ago
6 Comments ↓
🍀 meidam · 2025-03-21 at 14:31:
no
👻 ps [OP] · 2025-03-21 at 14:35:
I would add this quote from Gemtext specification:
Thus, a pair of ``` lines acts much like <pre> and </pre> tags in HTML.
— geminiprotocol.net/docs/gemtext.gmi
@meidam is it "no" yet?
👻 ps [OP] · 2025-03-21 at 14:36:
Ah, the key in
lines
Seems now I got it.
This makes gemtext *really* easy to parse and build clients for. You only need to look at the 3 first characters of a line to know what kinda stuff you're dealing with, really. When you reach the ```, "toggle" the "pre" mode/style, and done...
🚀 clseibold [🛂] · 2025-03-22 at 01:25:
No, gemini does not have *any* inline markup. Everything is line-based. People say this is to make it really easy to parse, and yes, it's technically easi*er*, but that doesn't mean inline markup isn't easy.
As for speed increase, it's marginal. Inline markup is just as insanely fast to parse, so I have to disagree with @HanzBrix on this: you can also have inline markup parsed by the time it has been transferred. It's insanely fast to parse inline markup, just like it's insanely fast to parse gemtext lines. The speed increase of no inine markup (when compared to inline markup) is marginal, barely existant. And yes, you *can* parse inline markup as it is streamed in, and yes, it is also extremely efficient.
To demonstrate what I'm saying, parsing a programming language is like 1% of the time and job of a compiler. Parsing in general is extremely insanely efficient and fast.
Markup languages don't have to do lexical analysis and dependency management and all this crap that compilers have to do.
Parsing markup is just insanely fast because it's barely doing anything except flipping a few bits here and there, and it's mostly linear one-pass parsing. The heaviest part of inline markup parsing is going to be memory allocation.
(As for *rendering* inline markup, that's a different story)
👻 ps [OP] · 2025-03-22 at 03:11:
Thanks guys,
Recently removed this my mistake from next ggemtext 0.6 version. It was incorrect implementation before, more of that, I had created lot of incorrect gmi documents and provided incorrect format description in few web articles.
The answer was in the only one specification word just. That because I never like massive documents for simple things.