💾 Archived View for rawtext.club › ~sloum › geminilist › 000405.gmi captured on 2020-10-31 at 01:33:28. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
FW: Text reflow woes (or: I want bullets back!)y

solderpunk solderpunk at SDF.ORG
Mon Jan 20 19:48:33 GMT 2020
- - - - - - - - - - - - - - - - - - - ```

On Mon, Jan 20, 2020 at 12:30:14PM -0500, Michael Lazar wrote: 
> By "parsing lists semantically" I mean that if I build an AST, I want all of
> the list items grouped together inside of single list object. This is how I
> did it when I was playing around with markdown a while ago [0]. From my
> research this seems to be the common way to do it [1].
> 
> Sophisticated gemini clients could utilize this is a variety of ways. Maybe
> you want to add a little bit of extra whitespace surrounding the list. Or you
> want to make sure that the your display does not cut-off half way through the
> list. Or you want to support re-ordering list items alphabetically. I don't
> know, the sky is the limit.

Got it, thanks for clarifying.

We'll never be able to stop people going nuts and defining their ownstructure on top of the official structure in the spec if they reallywant to, but I think if the official spec can define a perfectly flatstructure (such that actually building an AST is unnecessary) which isrich enough to take care of the most compelling styling that's needed toachieve good readability, then that's absolutely fine.  There's no needto have a concept of a list encapsulating consecutive list items inorder to implement the clean formatting I discussed previously, so Ithink we can do without it.  It might feel weird compared to HTML orLaTeX, but if it works, where's the problem?  I think this is how listswork in common troff macros, actually, but I can't swear to it. 
> I'm willing to admit that HTML has perhaps tainted my thinking here, but it
> just feels *wrong* to me to have an <li> without the surrounding <ul>. Doing
> the same thing with "paragraphs" (i.e. each line is a new paragraph) doesn't
> feel wrong in the same way. I just have a hard time mentally getting past it.

In the rough spec I sent around for this line-oriented syntax, each line*isn't* a new paragraph in any meaningful sense.  If you want verticalwhitespace between two parts of text which correspond to different linesbefore wrapping, you need to put a blank line in between them.  Thisfacilitatess things likeonewordperlinefor emphasis, acrostic poems, etc.

> When a client is wrapping a line longer than the viewport, the client may chose
> to add indents or other visual indicators to distinguish the beginning of the
> line from a continuation line. The simplest way to do this would be by adding a
> hanging indent to continuation lines.

Hmm.  An elegant idea, but I guess it would look quite strange forordinary text?

> Expanding on my previous code example:
> 
> ```
> def display_paragraph(line):
>     # Strip leading and trailing whitespace
>     line = line.strip()
> 
>     initial_indent = ''
>     subsequent_indent = '    '
>     wrapped_text = textwrap.wrap(line, initial_indent, subsequent_indent)
>     for line in wrapped_text:
>         print(line)
> ```

Aah!!!  I hadn't noticed that initial_indent, subsequent_indent featureof textwrap.wrap.  That makes handling unordered list items in theproposed way absolutely trivial!

def display_unordered_list_item(line):    # Strip * and any whitespace    line = line[1:].strip()    print(textwrap.fill(line, viewportwidth-2, "* ", " ")

Cheers,Solderpunk