Ambiguity in unordered list item definition

[solderpunk]

On Sun, May 31, 2020 at 01:55:26PM +1000, Thomas Karpiniec wrote:
> Hi,
> 
> While testing a GUI text/gemini renderer I noticed that if a line
> starts with an ASCII-emphasised word like this:
> 
> *Great* times are ahead
> 
> Then a spec-compliant browser will turn that into a bullet:
> 
>  •  Great* times are ahead

Yeah, I have noticed this too.  It's minor, like you say, but I will
admit it grates on me.

I guess there are a bunch of things we could do about this.

Solutions that involve changing the spec:

* We could introduce mandatory whitespace before the * character.
* We could replace * with - for list items.

Solutions that don't involve changing the spec:

* Authors could take care to introduce a leading space before text lines
  which begin with emphasised words.
* Geminispace could adopt a convention of emphasising words like _this_
  instead of like *this* (or any other way not involving *s).

I think if we were starting from scratch I would probably use - instead
of * for list items.  This maintains some familiarity from Markdown and
allows *this kind of emphasis* to exist unambiguously alongside
unordered items.  With the recent explosion of both software and content
I'm a little reluctant to change this now as it will make (a little,
yes) work for many people, and chances are good at least half of the
people who made things excitedly on the first weekend after the HN
article have now gotten bored and left and won't change anything, so
we'll end up with long-term visible inconsistencies (which will give
some people the idea that both * and - are valid, ala Markdown,
perpetuating the situation).  It would be a shame to do that for the
sake of something so minor.  Then again, maybe I should be less afraid
of breaking things.  All the content that exists today will hopefully be
a small percentage of all the content what will be created...

> I note that this would make it different from the headings, which
> specify optional whitespace. It would make parsing slightly easier if
> that whitespace was mandatory here too - as it stands, you must check
> for "###", "##" and "#" in that order so as to avoid "###Hello" being
> a top-level heading of value "##Hello".

It's true the checking needs to be done in "reverse" order, but I'm not
sure this is a big problem.  It doesn't need any *more* code than the
other way around, and it's a pretty obvious mistake to notice and fix if
people overlook it on their first try.

Cheers,
Solderpunk