`E121: Undefined variable: b:color_match_id` when switching buffers about vim-css-color

[ap]

I cannot reproduce this at all. But your #33 suggests that you have something in your configuration that reloads buffers when switching to them. Do you actually have something in your setup that discards buffers when you switch away – to the point of losing buffer-local variables?

[oryband]

Thx! I'll test the fix in the following days and will get back to you on this one.

[oryband]

This problem still occurs. I just noticed that it also happened when moving the cursor (pressing j for example), so it's not related to buffer switching. Also happens when splitting the window. Running autocmd CursorMoved shows this:

CSSColor  CursorMovedI
    <buffer=62>
              call s:parse_css_screen()
    <buffer=7>
              call s:parse_css_screen()
    <buffer=6>
              call s:parse_css_screen()
    <buffer=66>
              call s:parse_css_screen()
    <buffer=67>
              call s:parse_css_screen()
    <buffer=64>
              call s:parse_css_screen()
    <buffer=63>
              call s:parse_css_screen()
    <buffer=69>
              call s:parse_any_screen()

So I guess it has something to do with the s:parse_any_screen() function.

Any idea?

[ap]

What is wrong with that autocmd CursorMoved output? (Did you mean to post that comment in #33 instead of here?)

Do you mean that the b:color_match_id error still occurs? That is no surprise, as I didn’t fix it, as I don’t know what causes the problem – I do suspect it’s not my bug, but until you answer my question in this issue, I cannot say.

[oryband]

No, I just guessed the multiple s:parse_any_screen() was some sort of error. If you understand that it is not than that's ok.

Yes, the problem still occurs. All of my BufWinEnter commands are of of this kind: autocmd BufWinEnter *.html,*.htm setfiletype jinja, so I don't think that I have anything that discards buffers.

You can view my .vimrc here.

[ap]

The listing shows exactly one autocmd for each buffer where vim-css-color is active. That is as it should be.

[oryband]

When running that autocmd above, no ft=css (or ft=stylus etc.) buffers were open. Should this be executed for every type of buffer, even if it's ft=vim for example?

[oryband]

@ap is that okay?

[ap]

No, not for every type of buffer, just the supported file types – but vim happens to be one of those.

As for the undefined variable issue – I strongly suspect it’s not a bug in vim-css-color but rather caused by a bug in something else that’s in your config. But to verify that I’d have to grep through all the code in your setup – and since you use Vundle, I can’t just grep your repo to do that, I have to either install Vundle and replicate your config or manually clone all the repos your setup points to. I do want to do that, but it’s a fair amount of unfun work to confirm that (I assume) there is no bug in vim-css-color, so it’ll have to await a sufficient burst of motivation.

If you want to help, you could try starting with a minimal config with all other plugins turned off, and see if that reproduces the problem. I assume it won’t (but if it does then please Gist that config!), so then try with just one of your other plugins at a time, and see if one of them triggers the problem. If you can localise it that way, that would be a great help.

[oryband]

Yup, this is indeed a very unfun thing to do. :)
I’ll get to it when I have the time and get back to you.

Thanks for the help!

Ory Band - אורי בנד

[email protected] (mailto:[email protected])
OryBand.com (http://oryband.com/)

On Saturday, February 22, 2014 at 20:33, Aristotle Pagaltzis wrote:

No, not for every type of buffer, just the supported file types (/ap/vim-css-color/tree/master/after/syntax) – but vim happens to be one of those.
As for the undefined variable issue – I strongly suspect it’s not a bug in vim-css-color but rather caused by a bug in something else that’s in your config. But to verify that I’d have to grep through all the code in your setup – since you use Vundle, I can’t just grep your repo to do that, I have to either install Vundle and replicate your config or manually clone all the repos your setup points to. I do want to do that, but it’s a fair amount of unfun work to confirm that (I assume) there is no bug in vim-css-color, so it’ll have to await a sufficient burst of motivation.
If you want to help, you could try starting with a minimal config with all other plugins turned off, and see if that reproduces the problem. I assume it won’t (but if it does then please Gist that config!), so then try with just one of your other plugins at a time, and see if one of them triggers the problem. If you can localise it that way, that would be a great help.

—
Reply to this email directly or view it on GitHub (#32 (comment)).

[ap]

Hi @oryband, are you still having this issue? I’ve made some fixes for an unrelated issue today which may have resolved it. Can you test it and let me know?

[oryband]

@ap thanks, but I don't have the time and won't get to work with css files in the nearby future. you can close this issue.

[ap]

D’oh. Would’ve been nice to know… Oh well.

[oryband]

@ap sorry, but I opened this issue almost a year ago. nothing on purpose

[ap]

Oh I know, I wasn’t blaming you.

[joeytwiddle]

For what it's worth, I sometimes see this message too, although I'm not sure what leads up to it. (Possibly closing another buffer with :bwipeout, or reloading my syntax/highlight config?) Anyway thanks for the cool script, and for informing us of the update, I will pull and hopefully never post back here. :-)

[ap]

Possibly closing another buffer with :bwipeout

That seems very unlikely. If the buffer is wiped out, its matches array may be gone (and so are the matches, so that’s fine), but you can no longer switch to that buffer anyway – so how could this error happen?

or reloading my syntax/highlight config?

That seems much more likely. Not sure exactly how the chain of events in this case would go.