I've not even updated my Gemini page generation to take in to account the spec's expectation of line-wrapping.
I *could* update my Gemini page creation to take that in to account... But my source format is reStructuredText, and the expectation of hard line-feeds is baked in to that format. This also plays well with Gopher and HTML has no problems with it... The only outlier is Gemini.
Inconvenient parts of specs are just too easy to ignore.
@yam655 And yes I absolutely feel your pain. This is what I mean by Gemini feeling like work. Since we are implementing something we already have (text on screen) just so it’ll be slightly more hip?
Hanging indents break with simplistic line wrapping. Even if I'm mostly linking to media or plain-text files, every index page on the site is predicated upon functioning hanging indents.
Maybe the effect would be just as good in Gemini with soft line wrapping?
The bigger problem is that I want to rewrite the software I use to have a JSON-first design. If I'm going for light-weight versatile apps, Gemini doesn't cut it for my needs.
@yam655 How do you currently do these indents in RST?
With reStructuredText, I'm using an unordered list with a paragraph under the list item and indented to belong to that list item.
- something linked
paragraph under it.
- next item with a link
I'm pretty sure I can get the same effect just relying on the left-hand annotations provided by Gemini and Gopher for links and dropping the explicit list item markers. Will people get that it's an implicit list, though? I don't know.
Thank you for explaining, @yam655.
Yeah, that is basically the Gemini model. => is pretty much the equivalent of <li><a>.
@yam655 IOW I think people will clearly get that.
OMG @yam655 please unflow your text! Maybe you can go RST -> pandoc -> markdown -> md@gemini -> gmi? Hopefully pandoc gets a gmi writer down the line.
Yeah, I like having hardwrapped source docs too♥ Easier to edit esp w/ line editors like ed, sed, edbrowse, or ex.