💾 Archived View for rawtext.club › ~sloum › geminilist › 000398.gmi captured on 2020-09-24 at 02:35:55. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Michael Lazar lazar.michael22 at gmail.com
Mon Jan 20 02:01:17 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` I think there have been a lot of good suggestions coming from all sides. Here'smy take on a compromised format that tries to take everything into account whilealso inserting a few of my own opinions: Parser pseudo-code (actually, it's valid python):
'): display_link(line) elif line.startswith('---'): display_horizontal_rule() else: display_paragraph(line)
if preformat_mode: # Flush the preformat block if there was no end tag add_preformat_block(preformat_buffer)```
This pseudo-code was written with "fancy" gemini clients in mind. In otherwords, this should be close to the worst-case scenario for how complicated agemini document parser would ever need to be.
Many clients are going to want to display a preformat block of text in ahorizontally scrollable window or some other type of block widget. Thispseudo-code reflects that by sticking the pre-formatted lines in a separatebuffer until the end of the block. I think this is a more accuraterepresentation of what most client parsers would end up looking like.
I'm of the opinion that there should only be a fixed number of header levels.It keeps the matching logic flat and straightforward. Three levels is fewenough that most clients should be able to come up with distinct styles todisplay them. Fixed header lines are trivial to parse and provide a lot ofutility for organizing a document and linking to sub-sections.
Lists are tricky because while they would be nice to have, the complicate theparsing significantly. In order to parse a list while preserving its semanticstructure, you will need to keep track of where it starts and ends. Nestedlists complicate this even further, no matter which syntax for nesting is used.
Parsing lists semantically would require keeping a separate buffer for each typeof list, and then keeping flags and making sure that these buffers are flushedafter the last element in the list. Because of this, I do not believe that theypass the power-to-weight ratio smell test.
For authors, they still have a few choices for lists:
1. Stick the list in a preformat block2. Write the list in plain mode without special formatting
I accept that neither of these options is *ideal* for all use cases, but Ithink they are *good enough* for most use cases. Don't forget that unicodebullets can already be added directly in gemini documents if the authorwishes to do so.
Quote blocks with "
" would be ok if we could count on them being only a singleline long. However, many quotes will necessarily include line breaks thatshould be displayed together in a single block. This complicates parsing in thesame way that lists do, so I think that quotes should also be omitted for thesame reason.
If you want to display something like a quote from a mailing list message, Ithink that would be a perfect candidate for copying it into a preformatblock. For other types of quotes, stick them between two horizontal rules toseparate them from the surrounding text.
I find the horizontal rule useful for separating sections of a page. I see themcommonly use on gopher to add a footer to the bottom. They can likewise beused for header sections.
The following gemini sites already use some form of horizontal separator ontheir front pages (the precise syntax varies): - gemini://vger.cloud/- gemini://gemini.conman.org/- gemini://zaibatsu.circumlunar.space/- gemini://carcosa.net/- gemini://yam655.com/ I think that since horizontal rules are easy to parse and they add utility forstructuring pages, they should be included in the spec. ### Other Random Opinions - Leading and trailing whitespace should be stripped from all of lines outside of the preformat block. If you're allowing a non-monospace font for these elements, then leading whitespace can look inconsistent and trailing whitespace serves no real purpose. By leading whitespace, I mean that ## heading text Should be interpreted as "heading text", not " heading text".- I have no opinion on whether the ``` should allow text after it on the same line. I think I would be satisfied enough with the above document to at least try itout by converting all of my existing gemini content. I also think I would befine keeping everything fixed-width and hard wrapping. I *don't* think I wouldwant to implement nested lists or quote blocks, or anything significantly morecomplicated than what is outlined above. - mozz