[spec] comments on the proposed gemini spec revisions

[Omar Polo]

Oliver Simmons <oliversimmo@gmail.com> writes:

> On Mon, 11 Oct 2021 at 15:12, Omar Polo <op@omarpolo.com> wrote:
>> I've seen this argument in the gitlab issue too […]
>
> I haven't checked the issue yet, will do after sending this.
>
>> In what language(s) splitting a string is faster than
>> checking for a prefix?  Splitting requires the allocation of multiple
>> objects, while the prefix only requires a scan of the first few bytes.
>
> I said simpler, not faster. What you said is true in some cases, but
> not everyone is striving for optimisation speed-wise.

You didn't said "faster", true, but said that (emphasis mine)

> Not having a space means you'd have to test if the line starts with
> different things, which would be very annoying and **slower** in most
> cases.

I was contradicting that.

> It'll depend on the language used, but splitting allows you to use a
> simple equality switch statement, which isn't possible by checking
> with a prefix.

(btw, checking for equality inside a switch statement doesn't work for
strings in languages like C or Java.  Err... yes, it works, but it's not
same the equality you mean ;-)

> The way I understand your message, I would have to use an else-if
> list, which is hardly ideal.

This depends on the language design.  Some languages allows expression
inside switches, like Go IIRC, so you could write

switch {
case strings.HasPrefix(line, "*"):
	// ...
case strings.HasPrefix(line, "###"):
	// ...
...
}

other allows to do more elaborate things (clojure for example)

(defn has-prefix? [prefix str]
  (str/starts-with? str prefix))

(condp has-prefix? line
  "*"   :item
  "=>"  :link
  "###" :header-3
  ,,,)

Even when we take into account an ancient language like C, you could
take advantage that the first byte of a line is enough to get an idea of
its type and greatly reduce the number of chained ifs:

(this is more or less what I have in telescope)

switch (*line) {
case '*': return LINE_ITEM;
case '>': return LINE_QUOTE;
case '=':
	if (line[1] == '>')
		return LINE_LINK;
	break;
case '#':
	/* some ifs to check whether is a level 1, 2 or 3 */
	...
case '`':
	/* check for a ``` marker */
	...
}
return LINE_TEXT;

I don't think taking into account the particularities of one specific
programming language is a wise choice for a markup language meant to be
written by humans for humans.

The question should thus become: is it intuitive for a random user that

#hello world

and

# hello world

are effectively the same line?

Let's forget the code when tackling these issues, we think better when
we're not in front of a keyboard.

> [...]
>
> At the least, it should be required for link (as you said) and list
> lines ("* ").

Probably I was too ambiguous.  My point was that in a link line a space
in necessary between the link and the label, not after the marker.  So,
outside of the mandatory space to separate a link and its label,
whitespaces are irrelevant.

> I've seen where people have tried to use *emphasis* at
> the start of a line and got a bullet point by mistake.

I've seen people writing like that, and a conforming client (IMHO)
should consider those lines items.

It's like using => something like this <= to highlight text and then
complaining that a client mis-render a line because the author tried to
"highlight" the first words and now it's a link.

Who cares?  Gemini doesn't have inline formatting, so why bother trying
to support it?

(I've used some *emphasis* on some pages too, but more I write and more
I think I shouldn't, it's easier to read without too much noise.  That's
my opinion, at least.)

Anyway, whatever the final decision will be, I hope we could at least
ensure that all the clients are consistent in their rendering.

>> > I see no downside to enforcing it in the spec (a SHOULD or MUST).
>>
>> My argument is kind the opposite: if there isn't a (strong) reason for
>> requiring something, then that something MUST be optional.  Whitespaces
>> are required in the link line to separate unambiguously the link from
>> the label, the other whitespaces in the "special" lines don't serve this
>> purpose so they need to be completely optional.
>
> At the very least it should be recommended by the spec IMO.
>
> -Oliver Simmons (GoodClover)