Open azzarello opened 3 years ago
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):
#123
, #1234
, #112233
, #11223344
)white
, DarkTurquoise
, etc.)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…
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,'
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…).
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 asft=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:key=RGBA
Here is what this config looks like:
Although there is nothing interesting happening, I am also including a screenshot to show that these colors are not highlighted:![image](https://user-images.githubusercontent.com/10367472/119163804-9b23f480-ba10-11eb-9c1a-d38453c48c29.png)
P.S. I love the plugin (in my few weeks of usage) quite a bit, thank you for your work developing this!