LCD 047

This is probably a step in the right direction: 003751a.

@scrooloose: I think you essentially nailed it. The bigger issue is dealing in a meaningful way with loclists created by other plugins (or perhaps `lvimgrep`). Once this is solved, it...

@chrisbra: I'm not Martin, but I'd say such a patch would be useful but not enough. First, because we would still have to come up with some sensible behaviour for...

Ok, tagging would be something like this: a18a04b. The "tag" error is marked automatically as invalid, but that doesn't prevent it from being displayed. So this is not a viable...

@chrisbra: That's great, thank you so much! The patch that allows setting `w:quickfix_title` from `setqflist()` looks good, there isn't much to be said about it. The patch adding `getlocstack()` and...

@chrisbra: Sure, I'll post a note to vim_dev about `getlocstack()`. Re: windows numbers: you're right, there is an even deeper design problem there, but I don't think it has any...

@chrisbra: In that particular context, "except for (l)greapadd" translates to "(l)make" -- which is what I was claiming. Basically, `(l)make` creates a stack of loclists (each invocation adds a new...

Oh, I see: `(l)grep` is not the same as `(l)grepadd`, and there is no such thing as `(l)makeadd`. Sorry about that.

I committed a new branch [loclist_count](https://github.com/scrooloose/syntastic/tree/loclist_count), that makes syntastic reuse loclists whenever it's reasonably safe to do it. This doesn't solve the initial problem, but it does make `:lolder` and...

@blueyed: Yes, it's controlled by `g:syntastic_reuse_loc_lists`. But it's off by default (and undocumented) because of #1127. I never got to the bottom of _that_ problem either.