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

[solderpunk]

On Fri, Jan 17, 2020 at 09:16:27PM -0500, Sean Conner wrote:
 
>   Red alert!  Raise shields!  Strap in!  This is going to be a bumpy ride.

I'd have expected nothing less from you. :)  In fact, the very fact that
felt this abrupt change of direction was worth careful nit-picking
rather than dismisisng it with a fatal flaw up front is a plesant
surprise!

>   Not quite true, even according to this document.  Leading white space in
> lists is the glaring exception here.

I'll deal with this properly in the relevant part below, but there *is*
no leading whitespace in lists by definition.  "Begins with" means
"begins with"! :)
 
> > 5. HEADING LINES
> > 
> > Lines beginning with one, two or three consecutive # characters are
> > HEADING LINES, corresponding to headings, subheadings or susubheadings
> > respectively.  The text following the # characters (with leading
> > whitespace removed) 
> 
>   The parenthetical here is ambiguous.  Does it refer to this issue?
> 
> #A title
> ## A title with space between the '#' and text
> ###	Even more white space
> 
> or
> 
> #A title
>   ##A title with leading space before the '#'
> 	###Even more white space
> 
>   I'm thinking the former now that I'm replying, but my code deals with both
> cases combined, so I can handle:

Definitely the former.  Lines with leading spaces before the # do not
satisfy the definition of a HEADING LINE, which is any line that begins
with #, ## or ###

I'm open to reconsidering the leading whitespace thing.  I guess I was
thinking that some people might like to line up their headings in this
fashion:

#   Title
##  Section
### Sub-section 

and we should think of the top-level heading as "Title" and not "
Title".
 
>   Almost---tabs (and yes, I do use tabs---I like me the tabs) are an issue
> and while I can handle them (I have code that will expand them up to 8
> spaces) not everybody has code to deal with this.  So question:
> 
> 	WHAT ABOUT TABS?
> 
>   They WILL show up.
 
In headings???  I have no idea what to suggest regarding how to handle
that.  Is this such a deranged edge case that we feel safe letting that
behaviour be client-defined?

> > constitute the heading and should be displayed to
> > the user.  Clients MAY choose to apply special styling to headings to
> > distinguish them from ordinary lines.  However, the primary purpose of
> > HEADING LINES is to represent the internal structure of the document
> > in a machine-readable way.  Advanced clients can use this information
> > to, e.g. display a hierarchically formatted "table of contents" for a
> > long document in a side-pane, allowing users to easily jump to
> > specific sections without excessive scrolling.  Or CMS-style tools
> > automatically generating menus or Atom/RSS feeds for a directory of
> > text/gemini files can use the first heading in a file as a
> > human-friendly label for links to it.
> 
>   So another question.  I have some headings like this:
> 
> ### Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras sodales eget nisi quis condimentum. Donec ipsum arcu, fermentum eu ullamcorper sit amet, facilisis id nunc. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam tempus nulla ut dolor luctus malesuada. Suspendisse orci sem, semper at maximus non, pharetra et justo. Quisque lectus arcu, viverra ac convallis eu, vulputate ut enim. Nulla aliquam, lacus consequat suscipit facilisis, nisl tortor facilisis nisi, vel mattis eros arcu sed tellus. Duis quis lectus pellentesque, posuere dolor ut, sodales massa. Proin vel blandit mauris.
> 
> Given a screen width of 40, which of the four below should be displayed?
> 
> ### Lorem ipsum dolor sit amet, consect
> 
> ### Lorem ipsum dolor sit amet, cons...
> 
> ### Lorem ipsum dolor sit amet,
> ### consectetur adipiscing elit. Cras
> ### sodales eget nisi quis condimentum.
> ### Donec ipsum arcu, fermentum eu
> ### ullamcorper sit amet, facilisis id
> ### nunc. Class aptent taciti sociosqu
> ### ad litora torquent per conubia
> ### nostra, per inceptos himenaeos. Nam
> ### tempus nulla ut dolor luctus
> ### malesuada. Suspendisse orci sem,
> ### semper at maximus non, pharetra et
> ### justo. Quisque lectus arcu, viverra
> ### ac convallis eu, vulputate ut enim.
> ### Nulla aliquam, lacus consequat
> ### suscipit facilisis, nisl tortor
> ### facilisis nisi, vel mattis eros
> ### arcu sed tellus. Duis quis lectus
> ### pellentesque, posuere dolor ut,
> ### sodales massa. Proin vel blandit
> ### mauris.
> 
> ### Lorem ipsum dolor sit amet,
>     consectetur adipiscing elit. Cras
>     sodales eget nisi quis condimentum.
>     Donec ipsum arcu, fermentum eu
>     ullamcorper sit amet, facilisis id
>     nunc. Class aptent taciti sociosqu
>     ad litora torquent per conubia
>     nostra, per inceptos himenaeos. Nam
>     tempus nulla ut dolor luctus
>     malesuada. Suspendisse orci sem,
>     semper at maximus non, pharetra et
>     justo. Quisque lectus arcu, viverra
>     ac convallis eu, vulputate ut enim.
>     Nulla aliquam, lacus consequat
>     suscipit facilisis, nisl tortor
>     facilisis nisi, vel mattis eros
>     arcu sed tellus. Duis quis lectus
>     pellentesque, posuere dolor ut,
>     sodales massa. Proin vel blandit
>     mauris.
> 
> ### Lorem ipsum dolor sit amet,
> consectetur adipiscing elit. Cras
> sodales eget nisi quis condimentum.
> Donec ipsum arcu, fermentum eu
> ullamcorper sit amet, facilisis id
> nunc. Class aptent taciti sociosqu ad
> litora torquent per conubia nostra, per
> inceptos himenaeos. Nam tempus nulla ut
> dolor luctus malesuada. Suspendisse
> orci sem, semper at maximus non,
> pharetra et justo. Quisque lectus arcu,
> viverra ac convallis eu, vulputate ut
> enim. Nulla aliquam, lacus consequat
> suscipit facilisis, nisl tortor
> facilisis nisi, vel mattis eros arcu
> sed tellus. Duis quis lectus
> pellentesque, posuere dolor ut, sodales
> massa. Proin vel blandit mauris.
> 
>   Or is this way into the "you have *got* to be kidding!" territory?  I
> swear, I'm not trying to take these things to the extreme ... well, okay, I
> *am* trying to take these things to the exteme, but only to find out where
> the borders are.

You're right to do so.

Your last example is what would be produced by a simple client which
recognises only the compulsory line types (and hence treats heading
lines as text lines).

I think any of the others would be reasonable outputs for an advanced
client, although as a reader I would strongly prefer one of the
non-truncating options.  I'm not sure it makes sense to specify the
correct behaviour here, any more than it makes sense to specify what
kind of bullet symbol should be used for list items.

>   Okay, several questions here.  First off, replace the '###' with '*' in
> the above example---how to properly format a list item that is ridiculously
> long.

Well, a simple client that doesn't recognise list items as anything
special will just wrap it:

* To demonstrate endurance of humans and equipment in spaceflight for
extended periods, at least eight days required for a Moon landing, to
a maximum of two weeks

If we adopt this syntax, I would probably have AV-98 recognise item
lines and format the above like this:

* To demonstrate endurance of humans and equipment in spaceflight for
  extended periods, at least eight days required for a Moon landing,
  to a maximum of two weeks

i.e. instead of splitting the line into lines of length N, split them
into lines of length N-2, prefix the first line with "* " (or maybe find
some nice unicode bullet symbol) and prefix all the other lines with
"  ".  I suspect most clients will do something vaguely similar.  I'm
not sure we need to constrain this via spec, if somebody writes a client
which yields:

* To demonstrate endurance of humans and equipment in spaceflight...

nobody is going to want to use it.
 
>   Second question---this list:
> 
> * lorem
>  * ipsum
>   * dolor
>    * Fusce faucibus ... (I'll save you the text)
>    * Nunc pharetra ...
>   * consectetur
>   * adipiscing
>   * elit
>  * Cras
>  * sodales
> * eget
> * nisi
> 
>   This is a nested list, so the lines start with a blank line.  This list
> indents one space, but it could be two spaces per index, three, eight. 
> Also, this list:
> 
> * lorem
> 	* ipsum
> 		* dolor
> 			* Fusce faucibus ...
> 			* Nunc pharetra ... 
> 		* consectetur
> 		* adipiscing
> 		* elit
> 	* Cras
> 	* sodales
> * eget
> * nisi
> 
>   Uses tabs (ah, lovely tabs).  Are indents preserved?  Transformed?  What
> if there's mixed spaces and tabs (one line is a tab and two space, another
> line is 10 spaces---with a default tab stop of 8, they both line up)? 

Well, as I guess is clear by now, I don't consider most of those lines
to be list item lines because they don't start with *.  I had intended
nested lists to be unsupported, but I don't think I have a problem with
Tomasino's idea of permitting them via *** .  I'm still thinking on that
though.

> > 7. ORDERED LIST ITEMS
> > 
> > As above with obvious changes.
> 
>   Not so fast there!  Again, the same issues as above, but now here are some
> ordered lists that are obvious *to me* but maybe not to others:

Well, I guess a lot of your questions here are moot in light of my
earlier post about the + syntax.
 
>   -spc (Will torture specs for food ...)

You'll never go hungry!

Cheers,
Solderpunk