[MatthiasPortzel]

> Gemini documents certainly are never visually very attractive

As a proponent of the Gemini protocol, I take issue with this line. The Gemtext format is a minimal markup format for text documents. It's a way of semantically indicating "this part is plaintext", "this part is a link", "this part is a header". Unlike HTML/CSS, it does not provide a mechanism for the author to style their documents. Instead, it is up to the client to render the text document, however the client chooses. If most clients render text in an unattractive way, that's not a fault of the format. And I mean, I don't think plaintext is ugly.

Re: URL discussion

The author interprets "URL needs be UTF-8 encoded" as meaning that any escape codes in the URL need to use UTF-8. I interpreted that as meaning that the URL string as a whole should be UTF-8 encoded. In the author's example where there's a "%C5 in the URL", I'd just encode "%", "C", and "5" according to UTF-8. Maybe it goes without saying that the URL-line doesn't use UTF-16; but I think Solderpunk included it to be clear.

[Apreche]

URL discussion: This is exactly one of the author's points. The wording in the spec is too ambiguous. Different people reading it are interpreting it differently. No human language is really 100% unambiguous, but better technical writing here could increase clarity dramatically.

[ilyt]

> As a proponent of the Gemini protocol, I take issue with this line. The Gemtext format is a minimal markup format for text documents. It's a way of semantically indicating "this part is plaintext", "this part is a link", "this part is a header". Unlike HTML/CSS, it does not provide a mechanism for the author to style their documents. Instead, it is up to the client to render the text document, however the client chooses. If most clients render text in an unattractive way, that's not a fault of the format. And I mean, I don't think plaintext is ugly.

Okay? But why it isn't markdown? What does it add that markdown does not have ?

It is just taking few things from markdown but changing enough that markdown interpreter won't work. What's the point of that?. Different for sake of being different ?

I can understand say removing any support from HTML elements in markdown if you want to make something entirely new, but the changes are just entirely pointless and not make it more readable.

There appears to not even be a support for a basic table, while calling itself "rich document" format

But the cherry on cake gotta be this part of paragraph:

> You may have noticed that gemini supports links to other protocols (the above example includes a web link, beginning with `https`, and a gemini link, beginning with `gemini`).

The author is using `the markdown code/monospace font` backticks from markdown, in document describing this shitty format, where they are not implemented, out of habit of using them in markdown.

[zimpenfish]

> What does it add that markdown does not have ?

"a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec.

> There appears to not even be a support for a basic table

Given the number of Markdown table attempts I've seen over the years, I don't blame them for wanting to avoid that plague pit. Plus then rendering tables is another hellscape of torment.

[ilyt]

>> What does it add that markdown does not have ?

>"a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec.

If your device don't have enough memory to parse the markdown document it can just display it. That's not an useful feature of a format. Hell, if it is really a problem use subset of it instead of using half, then inventing own, worse way, to add URLs into the text.

>> There appears to not even be a support for a basic table

>Given the number of Markdown table attempts I've seen over the years, I don't blame them for wanting to avoid that plague pit. Plus then rendering tables is another hellscape of torment.

If you don't we're back in ugly land of mono font manually setting it up, that's why I think that should be included in bare minimum of any markup format. But that's kinda beside the point as originally MD didn't had it either.

[graypegg]

Gemtext has the pre formatted text fence that it specs as a mode-switch. Is that impossible with markdown? I think you could probably design every control symbol in markdown as a switch to “bold mode”, or “link content mode” and leave it at that. State machine style I guess?

[zimpenfish]

> Is that impossible with markdown?

No, that bit is the simple bit.

> you could probably design every control symbol in markdown as a switch

You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there. But also! If you do something like `# Header _*bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes. But on a non-header line, `_*bold-italic\nstill bold-italic*_` works fine because EOL doesn't cancel them. But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_*with mismatched_* middle *_attributes*_`).

In summary, Markdown parsing is a clusterfuck.

[ilyt]

> You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there

Requiring like, a byte, for state is hardly a complex requirement.

> But also! If you do something like `# Header _bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes.

And an IF statement or two.

> But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_with mismatched_* middle _attributes_`).

Fair enough, but you can't expect to get correct output if you put wrong data in, you are trying to italicize it twice. If the interpreteation was "either * or _ turns italics on/off" you'd also have not what you expected.

My complaint about markdown here is really that there are 2 ways to make italics and 2 ways to make bold text. "Just" having * for bold and _ for italics would on top of making parsing easy also make it clearer. Less typing too.

[zimpenfish]

> Requiring like, a byte, for state is hardly a complex requirement.

Add in table header and table cell to get to 128 states. You can probably get it above 256 quite easily. But the storage requirement isn't the point - it's that you have a complicated state machine where you can't just say "in-bold", "out-bold" as suggested because you also need "in-bold-whilst-italic", "in-bold-whilst-header", "in-bold-whilst-header-italic", etc. with the associated transitions.

Or you have a state machine for each attribute. But then `\n` can affect multiple of them at the same time and also require unwinding your state over a bunch of characters. You can say "this isn't beyond a competent developer", yes, but it is a long way from trivial to get correct.

> you are trying to italicize it twice.

Ah, HN mangled my example markdown. I should have remembered that happens.

[Karellen]

> But why it isn't markdown? What does [Gemtext] add that markdown does not have?

I think that's the wrong question. Based on what I've read of Gemini, its focus is on simplification. The question the Gemini authors are interested in would be "What does Gemtext remove from Markdown?"

To which the most obvious answer, as you point out, is "HTML".

As for "Why not use markdown with the HTML elements taken out?" - does the world really need another markdown variant that's less capable than the current lowest common denominator?

I would argue it's actually a better idea to just call it a different format altogether, rather than attempting to fragment the markdown landscape even further. It also helps to forestall the question of "Why not add HTML support, like all other markdown renderers?" If adding HTML support is an anti-goal (which I believe it is) then making it so that adding that support requires someone to actually implement an HTML renderer puts up more of a barrier than leaving the door open for someone to just switch out the markdown engine for one that already does.

[MatthiasPortzel]

The right comparison is comparing Gemtext to Markdown. I don't think Solderpunk or other Gemini users have any complaint with Markdown in particular.

The biggest problem with Markdown is that the vast majority of Markdown libraries convert Markdown to HTML. These are of course useless to implementing a native client that isn't based on HTML. (In addition, the CommonMark test suite is concerned with defining the correct HTML to output for a given Markdown input.)

So while Gemtext is heavily inspired by Markdown, there's no reason to introduce a reliance on Markdown.

[saghm]

> It is just taking few things from markdown but changing enough that markdown interpreter won't work. What's the point of that?. Different for sake of being different ?

Maybe an attempt to follow the philosophy of "avoid success at all costs", like the Haskell mantra?

[Groxx]

UTF-8: how does that view mesh with

>This scheme is syntactically compatible with the generic URI syntax defined in RFC 3986

^ that defines the percent encoding scheme.

About the only way I can think of is if Gemini URLs are a superset, and don't need to use percent encoding... but that means ambiguity when someone hands you a percent-encoded URL. Did they mean %C5 or %C5?

[layer8]

Maybe they really mean IRIs (RFC 3987).

[spc476]

There was some work on using RFC-3987 but it went nowhere as there was contention about how to handle international domain names---do you convert to puny code or not? Seriously, that's where it got hung up on.

[wdkrnls]

Lagrange makes Gemini pages look quite attractive in my opinion.

https://gmi.skyjake.fi/lagrange/