I know you use Jinja for markup parsing for the README 
files in the repos. Is there an issue with this where 
the first line can't start on a header markup?

I've noticed this in a number of my own repositories, 
as well as some others, e.g.

https://git.sr.ht/~jpgleeson/piaine/
https://git.sr.ht/~jpgleeson/spawsh/
https://sr.ht/~bhowell/quatch-express/

Is this an issue with files that were created on 
Windows possibly?

Cheers,
Jack

On Sun, Nov 15, 2020 at 12:22:22AM +0000, jack@jpgleeson.com wrote:
> I know you use Jinja for markup parsing for the README 
> files in the repos. Is there an issue with this where 
> the first line can't start on a header markup?

No, this is not related to Jinja.

In Markdown, one way to make a header is to make sure the first
character on the line is a hash (`#`). Looking at your README.md file:

$ curl -s https://git.sr.ht/~jpgleeson/piaine/blob/master/README.md |
    hexdump -C |
    head -1
00000000  ef bb bf 23 20 50 49 41  49 4e 45 0a 0a 49 73 20  |...# PIAINE..Is |

...we see that the first line contains the bytes EF BB BF in front of
the hash, which is why it's not detected as a header.

EF BB BF is the UTF-8 encoding of the Unicode Byte Order Mark, which is
some applications use to detect Unicode content, and to detect which
encoding it uses:

https://en.wikipedia.org/wiki/Byte_order_mark

I say "some applications", but in practice it's almost always Windows
applications, and specifically Windows Notepad that use a byte-order
mark, horribly confusing Unix tools that examine the first bytes of a
file and not the first printable character.

jack@jpgleeson.com writes:

> Is this an issue with files that were created on
> Windows possibly?

To further expand on the great answer of Tim, to fix that problem search the setting in your
text editor that explicitely avoids insertings BOM characters when saving a file.

cheers,

November 14, 2020 10:20 PM, "Tim Allen" <st@thristian.org> wrote:

>
> EF BB BF is the UTF-8 encoding of the Unicode Byte Order Mark, which is
> some applications use to detect Unicode content, and to detect which
> encoding it uses:
> 
> I say "some applications", but in practice it's almost always Windows
> applications, and specifically Windows Notepad that use a byte-order
> mark, horribly confusing Unix tools that examine the first bytes of a
> file and not the first printable character.

Thanks for this. That clears everything up. I can’t remember if either file was created in visual studio or sublime text, but both were definitely from windows.

Is this a case where the Windows behaviour isn’t according to spec and so sr.ht won’t support it?

On Sun Nov 15, 2020 at 11:22 AM EST,  wrote:
> Is this a case where the Windows behaviour isn’t according to spec and
> so sr.ht won’t support it?

There is a spec but it is a dumb spec so we shan't support it.