Support for conf ft files

[azzarello]

This is likely an edge case, so feel free to close this issue if it is not worth the trouble. Similarly if I somehow missed an issue that already addressed this, please also close this issue.
Now here's my use case:
I am editing the configuration file for my lockscreen (fork of i3lock) which is picked up by Vim as ft=conf, but the values are not highlighted. From my best guesses, there's 3 possible reasons I was able to imagine as to why this is happening:

1. There is no support generally for this specific filetype (potentially because there are so many different formats for the "extension-less config files"
2. The plugin doesn't pick up on syntax like key=RGBA
3. RGBA is not supported across all supported files (I saw an Issue where you described that this was fixed in a commit last year)

Here is what this config looks like:

# configuration file for betterlockscreen

insidecolor=00000000
ringcolor=ffffffff
keyhlcolor=d23c3dff
bshlcolor=d23c3dff
separatorcolor=00000000
insidevercolor=00000000
insidewrongcolor=d23c3dff
ringvercolor=ffffffff
ringwrongcolor=ffffffff
verifcolor=ffffffff
timecolor=ffffffff
datecolor=ffffffff
loginbox=00000066
font="JetBrainsMono Nerd Font"
locktext='Type password to unlock...'
lock_timeout=5
time_format='%H:%M:%S'

Although there is nothing interesting happening, I am also including a screenshot to show that these colors are not highlighted:

P.S. I love the plugin (in my few weeks of usage) quite a bit, thank you for your work developing this!

[ap]

Glad you like it 🙂

There are multiple reasons the colours in that file do not get highlighted, and they all come down to the fact that the plugin goes to a lot of effort to avoid colourising things that aren’t actually colours.

The first issue, which is not actually a problem, is that the plugin piggybacks on existing filetype syntax definitions to specify which portions of the syntax Vim should highlight – that way, f.ex., in CSS files, only colour names in property values get highlighted but not in property names. That requires supporting each filetype syntax individually. Since conf is not currently supported, there’s no way you’d get highlights in that file in the first place. But adding support for new syntaxes is simply one of the ways the plugin is improving over time, and the generic conf syntax does have both a confString and a confComment group. It’s not out of the question to add a definition for it that generically colourises arbitrary configuration files… at least for hash-marked RGB values, which tend to be pretty unambiguously colours.

The second issue, which is also not necessarily a problem by itself, is that this won’t help you because the plugin currently only supports at most the following forms (regardless of filetype):

1. hash-marked RGB values (#123, #1234, #112233, #11223344)
2. named colours (white, DarkTurquoise, etc.)
3. other CSS colour expressions (rgb(...)/rgba(...)/hsl(...)/hsla(...))
   The colours in that file are naked RGBA values without any kind of marker. So the plugin would have to be made to parse that form as well – which is not difficult.

The third issue, probably still not a problem, is that the colour values in your file are not syntax-highlighted at all, as anything. The way that the piggybacking works currently is that the plugin’s colorableGroup is added as containedin to a certain list of highlight groups from the the existing syntax. But there is no such group here. Probably this could be made to work, though.

However, this whole combination clashes with the overall goal of the plugin. Parsing arbitrary named 8-character hex strings as colours could be OK – if it were sufficiently constrained by the filetype syntax. But here that’s just a generic conf. 🙁 And just parsing any old 8-character hex value as a colour anywhere in any old conf file is no good…

[ap]

All that said, two things: betterlockscreen is just a shell script and the configuration is just read using source, so that’s not in fact some custom foorc file format… it’s just a plain ol’ shell script! You could declare it as such by adding a modeline (# vim: ft=sh).

However, there is still the “naked hex-string” issue. That could easily be fixed by @pavanjadhaw though by just changing the lock function in betterlockscreen. Instead of just passing the values of the variables as it currently does:

--inside-color=$insidecolor --ring-color=$ringcolor

… it would have to strip the hash from the front if there is one:

--inside-color=${insidecolor#\#} --ring-color=${ringcolor#\#}

Then you could write your config like so (making sure every color is in a string):

# configuration file for betterlockscreen

insidecolor='#00000000'
ringcolor='#ffffffff'
keyhlcolor='#d23c3dff'
bshlcolor='#d23c3dff'
separatorcolor='#00000000'
insidevercolor='#00000000'
insidewrongcolor='#d23c3dff'
ringvercolor='#ffffffff'
ringwrongcolor='#ffffffff'
verifcolor='#ffffffff'
timecolor='#ffffffff'
datecolor='#ffffffff'
loginbox='#00000066'
font="JetBrainsMono Nerd Font"
locktext='Type password to unlock...'
lock_timeout='#5'
time_format='%H:%M:%S'

… and either add the modeline or leave it out. (CSS Color would need a minor patch either way (as follows).) Then everything would work.

--- /dev/null
+++ w/after/syntax/conf.vim
@@ -0,0 +1 @@
+call css_color#init( 'rgba', 'none', 'confString,confComment' )
diff --git i/after/syntax/sh.vim w/after/syntax/sh.vim
index 8d7d6189bc0..7e9fce012cb 100644
--- i/after/syntax/sh.vim
+++ w/after/syntax/sh.vim
@@ -1,5 +1,5 @@
-syn match shCommentColor contained '\(#[^#]*\)\@<=\zs#\x\{3}\%(\x\{3}\)\?\>' containedin=shQuickComment,shBQComment,shComment
-call css_color#init( 'hex', 'none'
+syn match shCommentColor contained '\(#[^#]*\)\@<=\zs#\%(\x\{3,4}\)\{1,2}\>' containedin=shQuickComment,shBQComment,shComment
+call css_color#init( 'rgba', 'none'
        \, 'shSingleQuote,shDoubleQuote,shHereDoc,'
        \. 'shTestSingleQuote,shTestDoubleQuote,'
        \. 'shEchoQuote,shEmbeddedEcho,shEcho,'

[ap]

Alternatively, of course, if @pavanjadhaw doesn’t like changing betterlockscreen – since it’s just a shell script, you could add code to it to strip the hashmarks on your end (in any number of ways…).