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

[solderpunk]

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

As a reminder, the current spec-spec, version 0.9.2, basically defines
text/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, without
sacrificing support for arbitary screen width - at the cost of requiring
that clients be able to wrap lines.

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

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

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

Cheers,
Solderpunk