Add a dedicated Path => Syntax lookup database

[sharkdp]

Sublime text syntax definitions provide two different ways to "detect" specific languages:

• Via the file_extensions field in the header of the syntax. This allows us (for example) to choose the "C++" syntax for all files with a cpp file extension. It also allows us to choose the "Makefile" syntax for all files called Makefile¹.
• Via the first_line_match field in the header of the syntax. This allows us (for example) to choose the "Python" syntax for files that start with #!/usr/bin/env python - even without a .py extension.

It would be great if we could extend our "syntax detection" by allowing bat to choose a specific syntax for certain file path patterns. For example, it would be great if we could automatically use the "SSH Config" syntax for the file $HOME/.ssh/config (see #582). Or a (hypothetic) "X11 Config" syntax for all /etc/X11/xorg.conf.d/*.conf files. Or the "Shell" syntax for /etc/profile.

These examples would be rather hard to match with one of the above techniques as (1) the have very generic names and (2) they don't have a specific "first line pattern".

Before someone goes ahead and implements this, we should probably discuss both the general idea and the implementation details.

In any case, I'd be very glad to get some feedback on this idea.

¹ The file_extensions lookup does not actually distinguish between file-extension patterns and full-filename patterns. This means that a file called cpp will match the "C++" syntax and a file called foo.Makefile will match the "Makefile" syntax ☹️

[keith-hall]

re the footnote, it may be worth subscribing to this issue in case the situation will improve in future: sublimehq/sublime_text#1353

[sharkdp]

it may be worth subscribing to this issue in case the situation will improve in future: SublimeTextIssues/Core#1353

Thank you for the reference!

[gurgeous]

I love this idea and just today I was dreaming of a nicely highlighted sshd_config file... Could we use a regex match against the full file path?

[gurgeous]

I might be able to attempt a PR if you give me some direction. I'm an experienced engineer, though this would be my first stab at rust... It's ok to say no. I've been an open source maintainer too :)

[sharkdp]

I might be able to attempt a PR if you give me some direction. I'm an experienced engineer, though this would be my first stab at rust...

Sounds great! All contribution are very welcome.

I am happy to give directions / guidance, but probably not this week :-/.

[sharkdp]

This could also solve problems like #685 if we could add blacklist-entries of the form:

• map *.build to the C# syntax
• do not map files named build to the C# syntax

not sure how to best integrate this with the ideas above.

[cben]

I also want to help, hoping to scrath the particular itch that a file named Makefile.common was not highlighted.
assets/syntaxes/Packages/Makefile/Makefile.sublime-syntax now contains:

file_extensions:
  - make
  - GNUmakefile
  - makefile
  - Makefile
  - makefile.am
  - Makefile.am
  - makefile.in
  - Makefile.in
  - OCamlMakefile
  - mak
  - mk
first_line_match: ^#!\s*/usr/bin/make\b

Hmm, while I could add specifically Makefile.common there, it sounds like the intended semantics of file_extensions is a suffix of the path and it can't cover Makefile.*?

Now most of these files are upstream syntax definitions from Sublime, no?
If we add a new 3rd mechanism in bat, it'd require a separate configuration in bat, and we won't be able to add these config improvements back to the Sublime definitions — is that the idea?

[sharkdp]

Hmm, while I could add specifically Makefile.common there, it sounds like the intended semantics of file_extensions is a suffix of the path and it can't cover Makefile.*?

I don't think it can, no. For this particular example, I'm also not sure if we would want to add a rule like this. What about a file called Makefile.hs? I would actually expect this to be a Haskell file that deals with Makefiles (I chose Haskell because it's common to capitalize module names).

Now most of these files are upstream syntax definitions from Sublime, no?

Yes, most of them are.

If we add a new 3rd mechanism in bat, it'd require a separate configuration in bat, and we won't be able to add these config improvements back to the Sublime definitions — is that the idea?

No, we would not be able to contribute these changes upstream 🙁, but that's the idea, yes. Happy for any kind of feedback.

[sharkdp]

I made a first small step in this direction by implementing a (not yet comprehensive) test suite for syntax detection: #861

[sharkdp]

This has now been implemented (in a slightly more powerful way, using glob patterns) in #877

[sharkdp]

This has been released in bat 0.13.