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.