Turn it on for any file?

[bearcatsandor]

Oftentimes i find myself working with hex and rgb colors in files that wouldn't be considered in the filetype list that you have currently. Examples include discussions about color in email that i compose in vi, color settings in *.h files for the st terminal and just my own notes.

Would you consider a command that would turn on the colors for hex and rgb for any file regardless of syntax?

Thank you

[ap]

I do consider syntax-aware highlighting much superior to highlighting stuff willy-nilly, but having the option would still be useful in one-off situations, so I’m definitely not uninterested.

I just couldn’t ship that as the default, though – or even support it too obviously/easily –, because user requests are how support for more file types gets added. I fear that if I make it easy to turn on the plugin for any old file, users will just do that instead of coming to me to ask for support for their file type. That would not only mean they’re sticking themselves with a worse experience, it also breaks the mechanism by which the plugin improves for every other user. Which is unfortunate; but I don’t have a solution.

Even if it’s not going to become default or even obvious, though – I wouldn’t mind having some undocumented non-obvious way of doing it that I could tell users about individually when they ask for it (e.g. you).

Currently it‘s not possible, though. I looked at the code to see if I could find a trick to make it do that as it is, but its “contained containedin” arguments to the :syntax commands seem to make that impossible – I found no way to get Vim to define a syntax cluster that includes every group. So there would have to be some flag to make the code leave those arguments out, i.e. I need to implement support for it. Not hard – I just have to get around to it.

[ap]

And given all that, my counter-question is obviously: aren’t at least some those filetypes worth supporting specifically? Mail is obviously problematic but C headers sounds like a case of that, at least. How about you look at your use cases and create me some issues for filetypes that would be useful to you to be supported?

[bearcatsandor]

That all sounds reasonable. What would you need from me to get C headers supported?

On Wed, Feb 8, 2017, 18:29 Aristotle Pagaltzis ***@***.***> wrote: And given all that, my counter-question is obviously: aren’t at least some those filetypes worth supporting specifically? Mail is obviously problematic but C headers sounds like a case of that, at least. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgP4eEyDN3YG6xzoppQfkYbEoFsRAxks5ramu8gaJpZM4L7eCL> .

-- Bearcat M. Şándor, CEO Feline Soul Systems LLC Voice: 872.CAT.SOUL (872.228.7685) Fax: 406.235.7070

[ap]

Just the question of what part of the syntax do colour names appear in. In programming languages the plugin so far is generally conservative and only highlights within string literals and comments. Would that cover you?

[bearcatsandor]

I believe so. So far this is the kind of thing that I'm dealing with: static const char *colorname[] = { "#151515", /* 0: ANSI Color 0 */ "#9e7374", /* 1: ANSI Color 1 */ "#d69f74", /* 2: ANSI Color 2 */ "#747474", /* 3: ANSI Color 3 */ "#9d4a4c", /* 4: ANSI Color 4 */ "#734b4c", /* 5: ANSI Color 5 */ "#75a09f", /* 6: ANSI Color 6 */ "#fed974", /* 7: ANSI Color 7 */ "#74754c", /* 8: ANSI Color 8 */ "#9d0002", /* 9: ANSI Color 9 */ "#9e744c", /* 10: ANSI Color 10 */ "#747474", /* 11: ANSI Color 11 */ "#9d4b03", /* 12: ANSI Color 12 */ "#4c4a73", /* 13: ANSI Color 13 */ "#a0cecd", /* 14: ANSI Color 14 */ "#d7d99f", /* 15: ANSI Color 15 */ [255] = 0, [256] = "#151515", /* 256: Background */ [257] = "#747474e, /* 257: Foreground */ [258] = "#d7d99f", /* 258: Cursor */ [259] = "#1b1b1b", /* 259: Cursor Text */ /* No support for text highlight coloring; would be #151515. */ /* No support for highlight coloring; would be #a6cafe. */ /* No support for bold coloring; would be #ffffff. */ }; Thanks so much!

On Wed, Feb 8, 2017 at 8:47 PM Aristotle Pagaltzis ***@***.***> wrote: Just the question of what part of the syntax do colour names appear in. In programming languages the plugin so far is generally conservative and only highlights within string literals and comments. Would that cover you? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgP0kKYZxWzQxaL6Esp-jIZXg_ZkA6ks5raowbgaJpZM4L7eCL> .

-- Bearcat M. Şándor, CEO Feline Soul Systems LLC Voice: 872.CAT.SOUL (872.228.7685) Fax: 406.235.7070

[Chlorek]

It could just fallback to generic coloring scheme, when file is not specifically supported. Best of two worlds I think. Myself, I wanted to use it to edit some strange format configs, and to my surprise this plugin cannot do this. Would love to see such functionality.

[plexigras]

+1

[ap]

It could just fallback to generic coloring scheme

Actually, I have a better idea, and in retrospect I’m kicking myself that I didn’t come up with it sooner. Generally, I’ve been adding support for various filetypes by looking through their syntaxes and noting which of their highlight groups are ultimately linked to String or Comment. Well, if I can perform a formulaic task like that… i.e. an algorithm… then obviously so can a computer. (At least as long as that information can be introspected from a loaded syntax – which it can, if awkwardly.) D’uh.

This should only be triggered by a whitelist, but adding support for a non-unusual filetype would then be a matter of just adding its name to the whitelist. (Unusual filetypes might still require custom-configured setup, but it’s not hard to keep the ability to custom-configure filetypes.) Most filetype configurations that ship with the plugin (possibly even all of them) could just go away, replaced by an entry in the whitelist.

Now I just have to grind out an implementation of this.

[savchenko]

@ap , Is this still planned? :)

[ap]

@ap , Is this still planned? :)

Yes. Unfortunately it’s harder than it looks. I’ve made several attempts, but each time I’ve hit another snag just big enough for me to go do something else instead for the time being. I’m still convinced it’s doable – I’ve gotten further along with each attempt. It will just be somewhat involved and complicated, compared to how I initially pictured it, and I haven’t had the perseverance to see that through to conclusion.

[savchenko]

Thanks for such a quick response!

I have tried https://github.com/chrisbra/Colorizer (written by mr.Brabandt himself) and it works great apart from the fact that only one split can be highlighted at a time.

Have you considered "joining forces"? Both plugins are written in Vim script.

[amerov]

https://github.com/neoclide/coc-highlight can do it.
Maybe its source code can help to invent.

[ap]

Those plugins tackle a much easier problem, which is not hard to do for any file. CSS Color already has all the code needed to do that. But CSS Color goes beyond that and tackles a problem that to my knowledge no other plugin even tries to address: it doesn’t just find things that look like a colour and highlights them, it also knows which ones not to highlight.

Take for example this bit of CSS:

div.gold { font-weight: bold }
div.name { color: gold }

Other plugins will highlight both “gold” strings in there. CSS Color doesn’t. It only highlights the one that actually declares a color (i.e. the one on the second line).

Doing that requires specific knowledge of the filetype – at least given how Vim does syntax highlighting. Finding a way for a plugin to figure that out for arbitrary filetypes is hard (again, in Vim) – but that’s the problem I’m trying to solve. There are (to my knowledge) no forces I could join on this – no other plugin even remotely attempts to do this, or even just what CSS Color can already do.

Of course you may not care that parts of a file are highlighted which aren’t actually color definitions. I’m not saying you should, just that I do, and that that’s the reason for the things CSS Color can and can’t do. If you don‘t care, any of the other plugins will suffice.

[savchenko]

it doesn’t just find things that look like a colour and highlights them, it also knows which ones not to highlight.

Indeed, you are right. Testing the above-mentioned Colorizer on your snippet:

Have you considered adding an optional command that allows to "highlight all"?

Something like this:

1. "Smart highligh" by default, same as it is now.
2. If filetype isn't known - allow user to turn on opportunistic highlighting for whatever can be detected.

[ap]

Have you considered adding an optional command that allows to "highlight all"?

See #85 (comment)

[jpotier]

Have you considered adding an optional command that allows to "highlight all"?

See #85 (comment)

Could this adding to a whitelist be documented a bit more? I'm having trouble figuring it out. I want to use this plugin against a .nix file.

EDIT: meanwhile, I created: #143

[ThSGM]

Thanks for such a quick response!

I have tried https://github.com/chrisbra/Colorizer (written by mr.Brabandt himself) and it works great apart from the fact that only one split can be highlighted at a time.

Have you considered "joining forces"? Both plugins are written in Vim script.

Because of the lack of a toggle, I ended up switching from vim-css-color to Colorizer.

In fact, both plugins can be loaded and Colorizer defaulted to off.

[j-hui]

@ThSGM you can toggle this plugin by calling the css_color#toggle() function.

For convenience, I've defined this command for myself:

command! ColorToggle call css_color#toggle()

so that I can call toggle with just :ColorToggle.

There was also #119 at some point but not sure whether that got merged in.

Tagging #125 too --- even though that's closed, it's pinned and this seems more relevant to that issue's original question.

[j-hui]

To @bearcatsandor 's original question, I worked around this by defining my own hooks for my own filetypes. When a filetype is detected, will call css_color#init() with user-defined options, similar to what are found in the after/syntax/ directory this plugin defines.

function s:CssColorInit(typ, keywords, groups)
  try
    call css_color#init(a:typ, a:keywords, a:groups)
  catch /^Vim\%((\a\+)\)\=:E117/
    " echom 'ap/vim-css-color not yet installed.'
  endtry 
endfunction

augroup CssColorCustomFiletypes
  autocmd!
  autocmd Filetype conf call s:CssColorInit('hex', 'none', 'confComment')
  autocmd Filetype haskell call s:CssColorInit('hex', 'none', 'haskellLineComment,haskellString,haskellBlockComment')
augroup END

You could also call css_color#init() directly, but I wrapped it in my own CssColor function so that it wouldn't throw an ugly error if I didn't happen to have this plugin installed yet.

[Tocoe]

I'm not sure if this has been suggested, but have you considered allowing indiscriminate for whitelisted file types? by default the whitelist file could be empty of course.

Right now I'm trying to get syntax highlighting for Xresource theme files, which is so specific and i obviously don't expect official support for that. However, it would be cool if i could whitelist indiscriminate highlighting for only .Xresources.

[tehmasterer]

Interestingly, the colors work with i3wm's config file, but not the i3status config file.

I tried @j-hui 's suggestion above but I couldn't get it working. I'm not well-versed in Vim script so it's possible I did something wrong.

[Suletta-Majo]

I was looking for such a function to display color-coded colors on vim and came here.
Like the questioner, I wonder if it is only CSS, so I translated and read here.
In my case, I want to modify the following vim color scheme setting file, and I want to overlay colors for reference.
https://github.com/daylerees/colour-schemes/tree/master/vim/colors
If I search a little more, there may be a vim plugin for such a purpose.:/