Proposed minor spec changes, for comment.

[Luke Emmet]

On 21-May-2020 21:47, solderpunk wrote:
> On Tue, May 19, 2020 at 07:46:25AM +0000, solderpunk wrote:
>> So now the question is which do we prefer, forcing servers to
>> canonicalise (canonise?) everything, with client behaviour then being
>> strictly limited, or letting servers just send whatever the author uses
>> and forcing clients to accept any of CRLF, CR or LF?
>>
>> In general I have preferred pushing burden to server authors over client
>> authors for Gemini...but I expect the client burden is pretty small here
>> as most languages will have some kind of functionality for breaking
>> strings into lines which already handles this...
> Some quick experimentation with Python revealed that str.splitlines()
> is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.
> Encouraged by this, I made a single Gemini page that mixes all three
> styles in a single document:
>
> gemini://gemini.circumlunar.space/users/solderpunk/linebreaks.gmi
>
> I visited it with a selection of clients, but the results weren't
> encouraging.
>
> It rendered just fine in AV-98, because apparently Python is awesome at
> this.
As a client author, I think we have to expect a mix of line endings, but 
perhaps not commonly in the same document. But even this will happen at 
some stage when you have multiple authors contributing to the same file. 
Most text editors will handle this without complaint. I think it is not 
to be surprising that servers will generally just serve up the GMI file 
as is. End users/authors will simply use whatever text editor and os 
defaults it uses.

You can normalise them very simply just before display as follows (or 
similar scheme)

  - Replace all CRLF with LF in the document.
  - Replace all plain CR with LF
  - Then display, splitting at LF
  - Job done.

This is not onerous or a big performance hit as GMI files are in the 
grand scheme of things *very small* text files.

Works for me in my WIP client as a first approximation - the above link 
looks fine. But if the language has a library for this, we should just 
use it.

Best Wishes

   - Luke