Bad interaction with syntastic plugin since 7.4.2299 patch applied

[jsivak]

Here's the beginning of this issue: Undefined variable: b:syntastic_changedtick with after vim patch 7.4.2299 applied.

I've isolated this with a instance of vim running with only the syntastic and ferret plugins loaded.

I'm guessing this has something to do with how ferret and syntastic try to access/update the quickfix and/or location windows, since the error only occurs when I have syntastic displaying its error list in a location window.

Let me know what kind of info you need to further debug this issue.. not sure if other plugins will be affected.

[lcd047]

Syntastic maintainer here. I can't tell yet what's going on with the missing variable, but one problem that perhaps needs to be fixed in ferret is that Vim 7.4.2299 and later calls QuickFixCmdPre or QuickFixCmdPost for lgetexpr. This change makes little sense IMO (lgetexpr is almost never called interactively), but still, maybe ferret should be more selective about opening the error window without the user's intervention.

Also, the qf ftplugin applies to both quickfix and loclist windows, and ferret doesn't try to distinguish between the two. This means ferret will take over syntastic's loclists, even when configured to use quickfix lists itself.

[lcd047]

I just committed a fix that disables autocmds for lgetexpr on syntastic's side. This fixes the "unknown variable" message.

[wincent]

Also, the qf ftplugin applies to both quickfix and loclist windows, and ferret doesn't try to distinguish between the two. This means ferret will take over syntastic's loclists, even when configured to use quickfix lists itself.

I'd be happy to fix this if I can just understand the issue exactly. Are you referering to these settings? These intentionally apply to both quickfix and location lists, but there is a configuration option to suppress them if the user doesn't want this.

Or are you talking about these mappings (again, can be turned off).

(And from the other issue):

the other problems with ferret taking over syntastic's loclists remain

Can you let me know what you mean by "taking over" exactly, @lcd047? Will definitely fix if I can understand what is happening.

[lcd047]

Are you referering to these settings?
Or are you talking about these mappings

Both actually. Most of what ferret can do with loclists is harmful to syntastic. Syntastic uses loclists in two contexts: (1) when parsing errors from an external program; this loclist is essentially intermediate data, and is not intended to be shown in a window; and (2) when displaying errors in a window; this loclist is just constructed from an internal structure, it isn't the "master" copy. Syntastic also does things like making shallow copies of loclists to various buffers, for performance reasons. Syntastic also has its own logic for opening and closing the error window.

Consequently, opening an error window automatically is breaking syntastic's auto_loc_list. Changing the text of messages in a loclist makes it go out of synch with syntastic's internal structures and caches. Deleting lines from a loclist can make Vim crash. And so on.

Syntastic really needs to rely on loclists not changing under its feet. And sadly there is no safe way to tell syntastic's loclists apart from loclists created by other programs. For this reason it would be nice if ferret would have a mode where it just would stay away from loclists, and do its job exclusively with quickfix lists. It would allow me to tell people "configure X and you can safely use ferret along with syntastic".

[wincent]

This might be at least partly mitigated by #36.

Maybe I just need now to add some documentation for Syntastic users advising them that they might want to (probably) use g:FerretQFMap and (maybe) g:FerretQFOptions, in order to have things work in a non-conflicting way.

[wincent]

Closing this one due to inactivity. As I said in my previous comment, I expect this is at least partially mitigated now and the only real follow-up I can think of is to add a bit to the documentation. But right now, I don't feel confident enough about my recollection of all the details discussed two years ago to actually write that documentation, so I am just going to do nothing.