Feature request - flag to globally disable css_color.vim

[lifecrisis]

In #110, I requested code similar to the following;

if exists('g:loaded_css_color')
  finish
endif
let g:loaded_css_color = 1

to allow globally disabling this plugin from the user config files.

There seem to be two options:

1. If g:loaded_css_color is set, define the autoload functions to do nothing (like in the version check), so that all other scripts will be sourced but do nothing.
2. Check for g:loaded_css_color in all scripts.

If there is another/better way, I'd love to hear about it.

[ap]

Those are the only options I can think of as well. And both of them bug me, though I haven’t fully reasoned out my gut feel.

When I tried to articulate one reason that bugs me about checking the variable in every after/syntax script (back-compat with users’ custom scripts basically), I realised it’s a non-issue. I’m not sure how I’ll come down on this option; maybe I’ll go with that.

Doing it centrally is not great either. It seems rather weird for the loaded flag to not actually stop the plugin to from loading but to make it load do-nothing functions – doesn’t that kinda contradict the point of the flag? But the after/syntax scripts will throw errors without the do-nothing stub. Speaking of which, I dislike these stubs anyway – I just can’t figure out a good way around them (particularly given the back-compat constraint). So I’m not enthusiastic about that option. (Also, they feel less weird for handling the case where Vim is missing requirements than for the case where the user wants the plugin to abort loading.)

OTOH… copy-pasting the check into every single after/syntax script? Really? Maybe it sounds good now with the problem-solving blinders on (y’know… trying to force an answer and only considering the immediately apparent concerns). But will it still seem reasonable after living with it for a while? Somehow I doubt that too.

It’s frustrating that such a seeming no-brainer turns out to be kinda messy.

[lifecrisis]

Well, autoload/css_color.vim is never sourced unless one of the syntax files is triggered. So, really, checking for g:loaded_css_color in that file doesn't make a ton of sense. You would have to test for the global in all of the the scripts in the after/ directory.

Boilerplate like the following would work:

" Note that I added the second variable here to disable the plugin for particular file types.
if exists('g:loaded_css_color') || exists('g:loaded_css_color_php')
  finish
endif

I agree that boilerplate like this is almost never desirable. However, having an "off switch" like this allows a very nice level of granular control. Also, having each file follow this kind of template isn't all bad... the files in after/ are all very small, so there is little risk of making them unreadable or unwieldy.

As for getting rid of the function stubs, have you thought about adding a script in plugin/? The purpose of this script would then be to just do the version check and set the global g:loaded_css_color variable. When this is set, the checks in the after scripts will all fail, and error messages will never appear.

So, in plugin/css_color.vim, we would have:

" set the global loaded var to prevent the `after/` scripts from auto-loading functions
if v:version " ...
  let g:loaded_css_color = 1
endif

This is just a thought. After the fix in #110, I'm a happy user for the time being, so I have no further commentary to add here.

Thanks!

[ap]

You got me excited for a minute there until I realised that that cannot work… and then made me realise that actually the whole approach of checking the flag in the after/syntax scripts cannot work. The problem is that those scripts don’t just run once to load the plugin – they run (essentially) once per buffer, and their purpose is to initialise the buffer for colour highlighting (setting up autocommands and highlights etc.). Which makes your proposed per-syntax loaded flag particularly nonsensical.

I have to say… that was an unpleasant realisation. 😐

[ap]

So given that realisation I’m wondering about supporting a plugin load suppression flag at all. I already intend to add a feature to allow users to prevent the plugin from enabling itself in a buffer (globally and/or per-syntax) anyway (someday…). Maybe that would suffice, even if there’s no way to stop the plugin from loading outright.

[lifecrisis]

Which makes your proposed per-syntax loaded flag particularly nonsensical.

You seem to misunderstand my proposed solution. Notice that I am not saying you should set the load suppression global in any of the after/ files. The load suppression globals should only be checked there. The user is responsible for setting these variables to disable the plugin globally or for a particular file type. The proposed scheme will absolutely work.

Still, very low priority. I won't blame you if you decide not to support this.

[ap]

So…

It’s true that if g:loaded_css_color_foo is only checked in the corresponding after/syntax/foo.vim but never set by any code in the plugin, then that part would work.

The overall scheme however will only work if that is also true about g:loaded_css_color: under normal conditions it must not be set by anything in the plugin either. Setting it would prevent the after/syntax scripts from doing their job.

But then still calling it g:loaded_css_color is a misnomer. It works quite differently from the usual g:loaded_foo convention. That’s why I misunderstood you.

But you’re right in the substance, in that having a boilerplate check of some configuration variable in each after/syntax script would work.

[lifecrisis]

But then still calling it g:loaded_css_color is a misnomer. It works quite differently from the usual g:loaded_foo convention. That’s why I misunderstood you.

This is absolutely correct. I came very close to suggesting a new variable name above such as g:no_css_color or g:no_css_color_php. Naming is everything!

I apologize for the confusion. After re-reading my post above, I can see the lack of clarity on this point.

[ap]

No worries. 🙂

[ap]

So: it’s not going to be a loaded flag. Then that means there’s no imperative to try and keep the plugin from loading which means there’s no reason to copy-paste the boilerplate into every single after/syntax file instead of doing the check centrally in css_color#init().

This helps with another concern: that syntaxes may include other syntaxes, e.g. the HTML syntax loads the CSS syntax to highlight CSS inside <style> tags or style="" attributes. If the user disables the plugin for the HTML syntax then obviously it should not be initialised for the CSS syntax bits in the buffer either. This may require investigating the timing of what gets loaded when, and there may have to be a buffer variable or something to communicate from one css_color#init() call to another, or some such. It certainly would need that if the check is copy-pasted everywhere. With a centralised check, support for suppressing included syntaxes may just happen for free, by just having css_color#init() examine &syntax – which presumably always refers to the top-level syntax anyway. Or maybe not quite entirely for free, since &syntax may be a dot-separated list of syntaxes. I have some digging to do here.

[ssokolow]

such as g:no_css_color or g:no_css_color_php.

In my experience, the more idiomatic alternative to g:no_css_color_php is to have a b:no_css_color that the user can set via autocmd FileType or their own ftplugin/....

That way, you give the user maximum control over what they're disabling under what circumstances.

[ap]

If it works, yes. It’s a question of timing, I don’t know off the top of my head whether after scripts run after the FileType autocommand has been triggered. If they run first, then that wouldn’t work.