[spec] comments on the proposed gemini spec revisions

[Omar Polo]

Alex // nytpu <alex at nytpu.com> writes:

> [[PGP Signed Part:Undecided]]
> Hi all,
>
> Since I don't have (and am unable to create) a gitlab account, I wrote a
> Gemlog post detailing my responses to a bunch of the issues on the
> gitlab repos for Sean Conner's spec revisions.

I can wholeheartedly agree with the gitlab rant.  I've never used it
before and was quite shocked of how bad it is.  Even github is "decent"
in this regard, on a technical level at least.  I can at least *read* a
README, the code or the issues with w3m.

But it's a sailed ship.  We can only try to prevent similar moves in the
future.

> Posting here to increase the likelyhood that other relevant people will
> be able to see it.
>
> => //nytpu.com/gemlog/2021-10-10.gmi  Available over Gemini and HTTP

I'm not sure if this is the best place to reply to you post, but the
alternative would be to open gitlab, post your link under the mentioned
issues and reply there which... I don't really want to do it.  If I can
avoid open gitlab, all the better ;-)

1. whitespace after gemtext elements

I don't have strong opinion on this, but on the other hand I don't see a
real motivation to require a space in your post nor in the gitlab
discussion.  Whitespaces should not be mandatory if not strictly
required to separate fields (like in a link line) in my opinion at
least.  But yes, I do always write '# hello there' and not '#hello
there'.

2. BOM

> If you're making something for non-tech people to use and they use bad
> editors that include a BOM, it should be your responsibility to remove
> it before publishing the document.

I'm not sure this would be viable.  If you look at the original report
from Gnuserland you'd see a confused user that doesn't know what a BOM
is or how to deal with it.  He simply typed something in his preferred
text editor (which is mis-configured btw, why would someone on unix
force CRLF line endings is beyond my understanding), published and it
was slightly broken.

Declaring it out-of-scope for the protocol but reminding client authors
that bad documents may have a BOM in the best practice document seem the
most sensible solution to me.

I even thought about adding some kind of "feedback" to the user on how
the page is structured.  Say some kind of linter for things like hard
wrapping, bom, etc.  It may become annoying thought.

3. close_notify

Is it still a problem? :D

(Sometimes I've left dangling questions like this hoping for Bortzmeyer
to chime in and share some stats.  In the past it worked, hope he share
some this time too ;-)

4. dumb new feature proposals

I just love reading them ;)

Taking this in slightly OT direction: in what manner should client
authors experiment with extensions in their clients?  I know there isn't
a reply, if the project is mine I can do the hell I want with it, and
since most (all?) clients are free software I can take an existing one
and modify the hell out of it, and I'm grateful for this.

I know also the "don't extend gemini" mantra, and I repeat myself too.

But does improving how a document is rendered account as extending the
protocol?  If I, say, replace the "---" lines with a nice separator,
does it count as extending gemini or just a rendering nicety of the
client?

(multi-level lists gravitates too much toward the extension side I
guess, but who cares)

> ~nytpu