💾 Archived View for tilde.pink › ~slondr › re-tables-in-gemtext.gmi captured on 2023-04-19 at 23:11:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
A couple days ago,, moeris published an idea for a tabular formatted data content type in gemtext.
Moeris: About tables in gemtext (yes again ;)
The general idea is to add a new gemtext tag type, with the identifier |||, followed by a label on the same line, and then starting on the next line an ASCII-formatted table similar to Markdown or org-mode's (but not exactly the same).
The tabular formatted data ends with another ||| line, similar to ```.
The proposal for multiline and merged-cells table feels a lot more problematic. Gemtext is line-based; you can implement a gemtext parser with a fixed amount of global state and no lookbehind. In other words, the gemtext language is strictly more restricted even than context-free grammar.
To have multiline cells that span rows but not columns, you need to do one of two things:
1: Keep track of a possibly infinite amount of state per line, to match against the number of pipe characters, to render the table as was intended by the author
2: Never render anything and leave the ASCII as-is
(1) is actively non-desirable for gemtext, as it brings the format up a few complexity classes and makes writing a parser strictly more difficult.
(2) is fine, but offers no benefit over the current de-facto paradigm of just throwing ASCII-art-style tables into ``` tags.
Maybe you can make an argument that it's fine for clients to go with (2) but allow advanced clients to pick (1), but then we're going further down the path of widening the divide between "full featured" Gemini clients vs non-full-featured clients, and I don't want to see that divide widen any further.
At least, that's my two cents.