💾 Archived View for rawtext.club › ~sloum › geminilist › 007283.gmi captured on 2024-02-05 at 10:47:39. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[spec] comments on the proposed gemini spec revisions

Omar Polo op at omarpolo.com

Mon Oct 11 07:57:59 BST 2021

- - - - - - - - - - - - - - - - - - -

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 itbefore 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* aREADME, the code or the issues with w3m.

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

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 thealternative would be to open gitlab, post your link under the mentionedissues and reply there which... I don't really want to do it. If I canavoid 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 areal motivation to require a space in your post nor in the gitlabdiscussion. Whitespaces should not be mandatory if not strictlyrequired to separate fields (like in a link line) in my opinion atleast. But yes, I do always write '# hello there' and not '#hellothere'.

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 reportfrom Gnuserland you'd see a confused user that doesn't know what a BOMis or how to deal with it. He simply typed something in his preferredtext editor (which is mis-configured btw, why would someone on unixforce CRLF line endings is beyond my understanding), published and itwas slightly broken.

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

I even thought about adding some kind of "feedback" to the user on howthe page is structured. Say some kind of linter for things like hardwrapping, 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 Bortzmeyerto chime in and share some stats. In the past it worked, hope he sharesome this time too ;-)

4. dumb new feature proposals

I just love reading them ;)

Taking this in slightly OT direction: in what manner should clientauthors experiment with extensions in their clients? I know there isn'ta reply, if the project is mine I can do the hell I want with it, andsince most (all?) clients are free software I can take an existing oneand 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 theprotocol? If I, say, replace the "---" lines with a nice separator,does it count as extending gemini or just a rendering nicety of theclient?

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

~nytpu