Not working with sass variables about vim-css-color

[ap]

The result of the process should be patterns to search for and their corresponding color.

That is already how it works: the plugin scans the screen for colour literals and sets up highlights for them.

But yeah, I forgot that variables can be defined in other files (which, to complicate matters further, may or may not be currently opened for editing in another buffer, as well).

(The Principle of Least Power is rather relevant here.)

I'm not sure I'd like this feature anyway.

Those concerns don’t bother me so much. If the highlighting of variables could be toggled on and off then you could still get the benefits you described.

[ap]

All the colour literals are highlighted, are they not? 😄

Resolving variables would require running the whole thing through a Sass preprocessor on the fly on every keystroke (and understanding incompletely typed syntax). Not gonna happen in this plugin, sorry.

(I’d be curious if anything can do that in Emacs.)

[tuxflo]

Ok thanks for the reply. Thought it could be solved with a variable <-> color mapping...

"Emacs"? Never heard of that 😉 😆

[ap]

The mapping itself is the easy part. This plugin doesn’t even do that itself, strictly speaking. Once you know which variables exist and what values they have, you just tell Vim’s syntax highlighter about them, and the rest just happens, all by itself. (That’s the plugin’s job for colour literals. It doesn’t actively highlight anything itself.)

But to do that you have to find out which variables exist, and what values they have. And that’s a problem because any single keypress can change the meaning of the entire file. (Almost no keypress ever does. But keypresses that do change the meaning of at least a couple lines around the cursor are common.)

For colour literals, that’s also true, but it’s not really too terrible: you can scan just the current screen and ignore the rest of the file. Even if a keypress changed the meaning of the whole file, the user can never see anything more than what’s on screen anyway (by definition…). So as long as the current screen is always highlighted correctly, the user will never encounter incorrect highlighting.

But to deal with variables you cannot take any such shortcut. You have to scan the whole file on every keypress. And Vim’s scripting language is just too slow for that, for even moderately sized files. Just scanning the current screen alone can bog Vim down badly if there are a lot of colour literals.

That said – who knows. Maybe there is some other kind of shortcut. A different angle on the problem might reveal a feasible solution; maybe someday such an angle will occur to me. All I can say for sure is this feature is not doable in the obvious way.

[joeytwiddle]

I'm not sure I'd like this feature anyway. At the moment the plugin shows me where I can go to modify a color. Highlighting variables as well would make it harder to find the line where the color was actually defined. Also, currently if I see the same color in multiple places, this is an indication that I have duplicated the color code, and should probably clean it up (into a variable). That indication would not be possible if we highlight variables as well.

That said, I can see the value in the idea. And I want to suggest that it is not impossible to achieve, under the following conditions:

• The sass processing should be run in the background, perhaps using vimproc to call an external tool in a different language. This won't lock up/lag Vim, and we could reuse existing libraries to parse the SASS code (sass has implementations in Ruby and in NodeJS).
• The result of the process should be patterns to search for and their corresponding color. That will be much more lenient towards buffer edits than, say, line+column regions and their corresponding colors. So while we are waiting for the background process to complete, the highlighting will still be (reasonably) accurate.

But a complication:

• I'm not super familiar with SASS, but I fear to get a truly accurate value for every variable, we would need to process more than one file! And we might need to know which is the entry-point file to start from, which might only be known by your current %random_build_tool%'s configuration file/script. So good luck with that!