Commands to toggle syntastic_quiet_messages (style, warning, ...)

[blueyed]

I came up with the following to easily toggling type=style and level=warnings messages:

fun! SyntasticToggleQuiet(k, v)
  let idx = index(g:syntastic_quiet_messages[a:k], a:v)
  if idx == -1
    call add(g:syntastic_quiet_messages[a:k], a:v)
    echom 'Syntastic: '.a:k.':'.a:v.' disabled (filtered).'
  else
    call remove(g:syntastic_quiet_messages[a:k], idx)
    echom 'Syntastic: '.a:k.':'.a:v.' enabled (not filtered).'
  endif
endfun
command! SyntasticToggleWarnings call SyntasticToggleQuiet('level', 'warnings')
command! SyntasticToggleStyle    call SyntasticToggleQuiet('type', 'style')

Note: this assumes that lists are used and the keys are present, e.g.

let g:syntastic_quiet_messages = { "level": [],
      \ 'type': ['style'] }

I think that something like that would be useful to have in Syntastic by default.

It should get enhanced then to support non-existing keys and values as strings (as in https://github.com/scrooloose/syntastic/commit/355c36d0593fae55c6d4f8d3129522f40db36ddb).

[lcd047]

Filters with values [] and '' are now explicitly allowed, in the registry_refactor branch. You might want to check the updated manual.

[blueyed]

@lcd047 Good to know and have, but commands to toggle the global filters would still be useful.

[lcd047]

There are two ways to do this: (1) toggle various bits of what is displayed, and make the change take effect immediately on what is shown to the user, without re-running the checker, and (2) toggle filters, and make the change take effect the next time the checker is run.

(1) is the way the old syntastic_quiet_warnings used to work. That was user-friendly, and the implementation for a single filter (warnings / no warnings) was reasonable. Sadly, extending it to multiple filters would involve maintaining a full state machine. That would be a pain in the rear, and would prevent syntastic from ever adding a feature like YCM's checking on the fly. (Not that such a feature is planned for the foreseeable future; but it's still nice too keep it as a possibility, even if it's only a theoretical one for now.) In fact, removing syntastic_quiet_warnings simplified and accelerated the code quite a bit.

(2) is more or less what your function above does. Sadly, both the user interface and the implementation are messy. The user interface because it's really hard to let the user make multiple choices without things like checkboxes and buttons; and the implementation because you're trying to fit list- and regexp-shaped pegs into boolean-shaped holes. As Tim Pope likes to put it: how gross.

So, unless you (or somebody else) can come up with a radically different approach to all this, I'm afraid it's unlikely to happen. shrug