💾 Archived View for rawtext.club › ~sloum › geminilist › 002595.gmi captured on 2020-09-24 at 03:00:43. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

A proposed scheme for parsing preformatted alt text

Sandra Snan sandra.snan at idiomdrottning.org

Mon Sep 7 21:15:43 BST 2020

- - - - - - - - - - - - - - - - - - - 

This feels like the "hot comment" antipattern. Codifying a part of thelanguage that was meant for humans.http://wiki.c2.com/?HotComments

As for table output, I've been really happy with how the unicode tablesfrom md2gemini look. I have used many many ASCII tables via org-mode andpandoc markdown. Which I use depend on the source data.

For a table that's primarily meant to be seen and used (like the D&Dtables I've posted) by humans I think the unicode tables are great.

And, you _can_ extract the fields and records from them:The fields are separated by │ characters and whitespace.

Screenreaders could set those characters to silent and then read off thevalues in each row separately.

For data that's meant for computer usage, it's easy to convert theunicode tables to computable data, but a separate TSV file (orsexps, XML or even JSON) is better.

That's kind of how I see the gem files, and I mean the following as awarm compliment: they're glorified index listings. The "one link perline" is a great structure for actually linking to actual files.

While I'm on the topic of one link per line, the whole numbers in theparagraphs to refer to line links style is not cool. Its as if you wantinline links. If you wanted inline links then why didn't you put them inthe spec?

The spec was designed by someone who wanted text paragraphs followed by(or preceded by) lists of links. _Pages_ are hypertext, but the proseisn't.