E803: ID not found in s:clear_matches on BufWinLeave

[companygardener]

Description

s:clear_matches() in autoload/css_color.vim calls matchdelete() on stored IDs without checking whether they still exist, causing E803: ID not found when another plugin or autocommand has already cleared the matches.

Steps to Reproduce

1. Have NERDTree (or any other plugin that triggers BufWinLeave) installed
2. Open a file with CSS colors
3. Use NERDTree to navigate to another file
4. Error is thrown:

Error detected while processing function nerdtree#ui_glue#invokeKeyMap[1]..78[18]..77[3]..<SNR>78_activateFileNode[1]..107[1]..123[3]..179[6]..180[17]..15[3]..
BufWinLeave Autocommands for "<buffer=8>"..function <SNR>148_clear_matches:
line    1:
E803: ID not found: 1027

Root Cause

In autoload/css_color.vim around line 206:

function! s:clear_matches()
    call map(get(w:, 'css_color_match_id', []), 'matchdelete(v:val)')
    let w:css_color_match_id = []
endfunction

The match IDs stored in w:css_color_match_id may have already been removed (e.g. by clearmatches() or another plugin), so matchdelete(v:val) throws E803.

This is the same class of bug as #42, which was fixed for s:update_matches but not for s:clear_matches.

Suggested Fix

Wrap the deletion in a try/catch:

function! s:clear_matches()
    for l:id in get(w:, 'css_color_match_id', [])
        try | call matchdelete(l:id) | catch /E803/ | endtry
    endfor
    let w:css_color_match_id = []
endfunction

Or validate against existing matches first:

function! s:clear_matches()
    let l:existing = map(getmatches(), 'v:val.id')
    for l:id in get(w:, 'css_color_match_id', [])
        if index(l:existing, l:id) >= 0
            call matchdelete(l:id)
        endif
    endfor
    let w:css_color_match_id = []
endfunction

[ap]

Have NERDTree (or any other plugin that triggers BufWinLeave) installed

I don’t see how triggering BufWinLeave can cause this – s:clear_matches clears the list of match IDs after deleting them. Can you trigger the bug with no other plugin involved?

This is the same class of bug as #42, which was fixed for s:update_matches but not for s:clear_matches.

I don’t know what this means. There was never any change made for this to s:update_matches, and s:clear_matches now contains the exact same code that was previously in s:update_matches.

The match IDs stored in w:css_color_match_id may have already been removed (e.g. by clearmatches() or another plugin), so matchdelete(v:val) throws E803.

Why is the other code removing matches it didn’t create? CSS Color is throwing an error because it is being careful to only remove matches it itself created. If those matches were already deleted by other code, then the bug is in the other code which is deleting someone else’s matches, not in CSS Color. (Calling clearmatches() in particular is pretty much by definition a bug – it’s unfortunate that Vim even has this function at all.)