💾 Archived View for rawtext.club › ~sloum › geminilist › 000413.gmi captured on 2020-10-31 at 01:33:47. Gemini links have been rewritten to link to archived content

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

Text reflow woes (or: I want bullets back!)y

solderpunk solderpunk at SDF.ORG

Tue Jan 21 20:06:54 GMT 2020

- - - - - - - - - - - - - - - - - - - ```

Okay, it looks like we are not as close to a consensus as I had hoped orimagined. That's fine. I don't want to rush this process, as much asI'm looking forward to it being over. I wonder if we can make a simpleincremental improvement to the spec-spec now, though, using some of theideas that have come out of this latest round of discussion.

As a reminder, the current spec-spec, version 0.9.2, basically definestext/gemini thusly:

Lines beginning with =

> are links* Links must always be displayed on their own lines* All other lines are just text* Text may be optionally reflowed as per RFC 1896, i.e. by turning isolated newlines into spaces and N consecutive newlines into N consecutive newlines.

That's it.

This format:

Gives us links* Results in nice text on arbitrary width screens* Completely breaks lists like this one by joining all items together

(this last point kicked off this gigantic email thread)

We could change this to the following:

Lines beginning with =

> are links* Links must always be displayed on their own lines* All other lines are just text* Lines of text wider than the screen should be wrapped to fit the screen, but no RFC 1896 style mangling of newlines is allowed* Authors are strongly encouraged not to hard-wrap their text but to write long lines instead.

This format:

Gives us links* Results in nice text on arbitrary width screens* Lets lists like this one work just fine

i.e. it solves the problem that kicked off this email thread, withoutsacrificing support for arbitary screen width - at the cost of requiringthat clients be able to wrap lines.

Does anybody *disagree* that this change by itself would improve thecurrent spec-spec?

I think this is, in fact, the smallest possible change to the currentspec-spec which solves my original complaint without sacrificing supportfor arbitrary screen width. So maybe I should rephrase that question:

Would anybody *prefer* that we spec hard-wrapping to some specifiedlength (80, 40, whatever) over speccing the above "long line" solution?Please speak up if so!

Cheers,Solderpunk