💾 Archived View for skyjake.fi › gemlog › 2021-10_re-mark-it-down.gmi captured on 2023-01-29 at 15:48:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Some responses to my post
I would prefer a Markdown parser to emit valid gemtext instead of HTML.
Such things already exist, for example md2gemini and 7off. I can appreciate the difficulty of the endeavor having just written an incomplete Markdown translator for Lagrange. Having this as part of the authoring workflow may be a great solution for anyone who likes to write in Markdown and doesn't mind the limitations of Gemtext.
You could actually plug md2gemini into Lagrange right now as a `text/markdown` MIME hook, and it would probably render you some nice gemtext pages.
gerikson continues later:
I'd love to use a client that parses _italic_ and **bold** like Markdown does.
Speaking of Lagrange MIME hooks, it's possible to write one that converts those characters to ANSI font escapes. These will be supported in Lagrange v1.8 (although disabled by default).
kevinsan commented on Station:
it's more the tendency to wite markdown for the rendered effect, rather than source readability.
IMO, if one isn't concerned about how a Markdown document looks like in its source ASCII form, one should just use a WYSIWYG format instead. I suspect the web is to blame here...
A vehement "no" from idiomdrottning,
(who is actually a big fan of Markdown):
Really disagree with the idea to put Markdown out there.
It’s even harder to parse and emit correctly than XML.
...
Markdown is really human centric. As an editor tool, basically. I use it and love it, but then carefully choose the settings that make sense for each particular export.
I don’t think a network based on markdown parsing makes sense or is a good idea.
The crux of the argument being that while Markdown is great for humans to write in, it can be ambiguous to interpret and thus behaves inconsistently depending on the parser. Such a format is ill-suited for network communications as the parties may disagree about the semantics of the markup. Therefore, in practice one always needs to be mindful of which generator is being used when converting Markdown to a visual format.
I would argue that
there is CommonMark to address this problem.
Granted, the spec hasn't been finalized, and in its entirety it's way too large and complex for the smol net. Hence the need for some subset.
---✀---✀---✀---
Markdown is a media format among many, and it makes sense to use it for some content and not for others. I could publish all my posts as, say, JPEGs, but that's clearly not a great fit even though it allows truly arbitrary formatting. Markdown is overkill for most gemlog posts, but not everything: for example, if I'd like to write a long article with a bunch of tables and internal cross-references, having it be Gemtext is not the best fit.
Since a core part of the issue is that the source document cannot always be faithfully reproduced as intended, maybe it should be up to the user to decide if they want to view the raw source or a rendered version of it. The client shouldn't force either view on the user.
This seems much more contentious, and also a bit of a tangent from the Markdown topic.
For the record, I'm going to disable Lagrange's upcoming ANSI font escapes by default on Gemtext pages. Extending Gemtext with a font markup mechanism is not something I want to do.
I also really disagree with the ansi font support. Please don’t do this.
The reasoning here was that these escapes can mess with screen readers and cause fragmentation both between terminal and GUI clients, and cause potential display issues in GUI clients not prepared for them.
I actually fully agree with that. ANSI escape sequences should probably be banned from `text/gemini` entirely, or at least from line types other than preformatted blocks. However, the specification does not address this directly. It lets clients choose how to style text, and allows ignoring any visual formatting directives that the author may have managed to include.
marmaladefoo replied on Station:
I was more concerned at your remarks that you will support ANSI codes in gemtext. I think this is a direction to be avoided - ANSI codes are really a very specific implementation technology (console control codes) inlined into text. Its like having <font> tags embedded in gemtext or other content and expecting that clients will render it.
Indeed.
---✀---✀---✀---
Why leave it as an option, though? Well, ANSI (color) codes are in use already, for example on AstroBotany. Font style codes are not fundamentally any different, so allowing changing the color but not the font style seems arbitrary. Optional font markup could also have nice local uses via MIME hook filters.
Terminal-based clients support ANSI escapes for free unless they are specifically filtered out. Wouldn't it be nice if terminal and GUI clients could have some feature parity in this regard, if the user so wishes?
Work on v1.8 continues, so nothing is set in stone. Let me know if you have further thoughts or comments.
📅 2021-10-14
CC-BY-SA 4.0