💾 Archived View for rawtext.club › ~sloum › geminilist › 000370.gmi captured on 2020-11-07 at 01:26:36. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Text reflow woes (or: I want bullets back!)y

solderpunk solderpunk at SDF.ORG
Sat Jan 18 18:34:56 GMT 2020
- - - - - - - - - - - - - - - - - - - ```

On Sat, Jan 18, 2020 at 06:39:47PM +0100, Julien Blanchard wrote:

> I'm really glad this conversation is coming to a conclusion which so far
> seems to satisfy
> everybody and we can finally move on to other topics!

Me too!  Although I'm still very keen to hear from jmcbray on theserecent developments.  I *suspect* they'll be happy.  But I really don'twant to rush into this.

But I am amazed at how much more tractable getting away fromgopher-style hard wrapping has made this whole discussion.  It has madeit obvious to me that the problem all along has been with determiningthe scope of special features.

Consider bulleted lists, with hard-wrapping.  Suppose we have thiscontent, hard wrapped to 40 characters, and our viewport is 60characters so we want to combine lines:


	To demonstrate endurance of humans and    | Line 1equipment in spaceflight for extended       | 2periods, at least eight days required       | 3for a Moon landing, to a maximum of two     | 4weeks                                       | 5* To effect rendezvous and docking with     | 6another vehicle, and to maneuver the        | 7combined spacecraft using the               | 8propulsion system of the target vehicle     | 9* To demonstrate Extra-Vehicular            | 10Activity (EVA), or space-"walks" outside    |the protection of the spacecraft, and to    |evaluate the astronauts' ability to         |perform tasks there * To perfect            |techniques of atmospheric reentry and       |touchdown at a pre-selected location on     |land                                        |


Any old client can recognise that Line 1 is a list item by virtue ofthe leading *.  But in order for a client to do a nice job ofreformatting this list to 60 chars, it has to understand that lines 1through 5 constitute a single list item (i.e. that this is the scope ofthe * in line 1), and that lines 2-5 are not an independent paragraphof text coming after a list with only a single item.  To a human, thisis obvious, even if they can't read English, because the list items atlines 6 and 10 make it clear.  But to a parser, at the time itencounters line 2, it has no idea what's in lines 6 or 10.  So parsingrequires looking ahead, and understanding rules like "Once started, alist item continues until we encounter either a new list item or a blankline".  It's exactly that kind of fiddly rule that I was terrified offilling the spec with earlier.

In HTML, the scoping problem is trivial, because there are explicitbeginning and tags, <li> and </li>.  Markdown gets rid of these forvisual lightness (great!), but that scoping information is stillessential.  In Markdown it's in there implicitly for a sufficientlycomplicated (bad!) parser which understands the concept of blocks(which can be nested).  So Markdown trades the visual complexity ofHTML for conceptual complexity that makes it a pain to parse.

The syntax we're now talking about, where scope is limited to a singleline, is such an elegant alternative to both of these!  One way to thinkabout it is that things like =
>, * and # are differnet kinds of openingtag but they all have the same closing tag, which is \n.  Because thereare opening and closing tags, the parsing is easy, like HTML.  Butbecause our closing tags are invisible and need to be there anyway, weget ease of authoring and visual lightness like Markdown.  It's the bestof both worlds.

I'm so glad we hit upon this before I ran out of patience and justdeclared Gopher-style plain text hard wrapping to be the final decision!Thanks to everybody who steered the conversation in this direction.

Cheers,Solderpunk