3 ms·

> 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 semantical

by ilyt 3y ago

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

MatthiasPortzel 3y ago
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.
zimpenfish 3y ago
> 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.
- graypegg 3y ago
  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 3y ago
    > 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 3y ago
      > 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.
Karellen 3y ago
> 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.
deleted 3y ago
[deleted]
saghm 3y ago
> 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?

by ilyt 3y ago

MatthiasPortzel 3y ago

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.

zimpenfish 3y ago

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

graypegg 3y ago
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 3y ago
  > 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 3y ago
    > 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.

Karellen 3y ago

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

deleted 3y ago

[deleted]

saghm 3y ago

> 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?