I’ve been wanting to show projects I’ve written off in a smaller progamming
language community. Currently it and its config file langauge are in a syntax
not supported by Pygments (which I believe is the highlighter, yes?). While
syntax highlighting isn’t the most important feature, it does affect the
perception of the platform. Specifically not having comments de-emphasized makes
it hard to read code.

I’ve added support to Highlight and helped adding it to Prism in the past, but
do not have the bandwidth or desire to help with Pygments. However, it seems
a bit restrictive to make all languages open a merge request with that project
to get support on Sourcehut–especially for new/toy languages. In my case being
able to tell Pygments to highlight as Haskell would give me good-enough results.

When I think about this space, I think of files with comments like:

# vim: syntax=sh

GitLab uses .gitatttributes to hint
(https://docs.gitlab.com/ee/user/project/highlighting.html). I would be happy to
see something like this for Sourcehut, to set:

*.dhall       srht-language=haskell
*.purs        srht-language=haskell
*.sss         srht-language=sass
*.webmanifest srht-language=json

--
toastal ไข่ดาว | https://toast.al
PGP: 7944 74b7 d236 dab9 c9ef  e7f9 5cce 6f14 66d4 7c9e

I think it's quite reasonable to suggest sending your patch to Pygments.
That improves not just sourcehut, but many other platforms as well,
which ultimately makes a better ecosystem for your programming language.
It's pretty easy to contribute new lexers to Pygments.

On Thu Oct 14, 2021 at 6:54 PM MSK, toastal wrote:
> I’ve been wanting to show projects I’ve written off in a smaller
> progamming
> language community. Currently it and its config file langauge are in a
> syntax
> not supported by Pygments (which I believe is the highlighter, yes?).
> While
> syntax highlighting isn’t the most important feature, it does affect
> the
> perception of the platform. Specifically not having comments
> de-emphasized makes
> it hard to read code.

I agree that this is useful, though I don't usually read code in the
browser so this is less of a problem for me.

> When I think about this space, I think of files with comments like:
>
> # vim: syntax=sh

Pygments actually supports using those via get_filetype_from_buffer.
It's not presently used on Sourcehut, but this is an easy fix.

It's in my opinion not the best solution because you'd have to add
this modeline in every file, entries in .gitattributes or something
like it might be better.

> *.dhall       srht-language=haskell
> *.purs        srht-language=haskell
> *.sss         srht-language=sass
> *.webmanifest srht-language=json

Would be better if it was 'language' instead of 'srht-language' to make
it platform neutral.

> I don't usually read code in the browser so this is less of a problem for me

I usually do though. When assessing a new library or executable, I’ll prefer to look over it in the browser. I can’t think of a time where I did a git checkout just to read the source or a tag’s commit messages to see the release notes. Language community tooling often points repos to read in this manner as well.

> Would be better if it was 'language' instead of 'srht-language' 

No opinion. GitLab prefixed their implementation so I can only assume there was a strong reason to do this, possibly as it's not standard.

-- 
toastal ไข่ดาว | https://toast.al
PGP: 7944 74b7 d236 dab9 c9ef  e7f9 5cce 6f14 66d4 7c9e

On Fri Oct 15, 2021 at 5:28 AM MSK, toastal wrote:
> > Would be better if it was 'language' instead of 'srht-language' 
>
> No opinion. GitLab prefixed their implementation so I can only assume
> there was a strong reason to do this, possibly as it's not standard.

Well yes, properties in .gitattributes are not really standard but
I think it would be nicer to not tie them to Sourcehut from the start.