On 3 September 2016, Bram Moolenaar <[email protected]> wrote:
>
> Lcd wrote:
>
> > > > On 1 September 2016, Bram Moolenaar <[email protected]> wrote:
> > > > >
> > > > > Patch 7.4.2299 Problem: QuickFixCmdPre and QuickFixCmdPost
> > > > > autocommands are not always triggered. Solution: Also
> > > > > trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
> > > > > Files: src/quickfix.c, src/testdir/test_quickfix.vim
> > > > [...]
> > > >
> > > > Sadly, this breaks the interaction of "syntastic" with all
> > > > plugins that hook to QuickFixCmdPre or QuickFixCmdPost. An
> > > > example of such plugin is "ferret". These plugins now have to
> > > > be fixed to be aware that they may be called from things like
> > > > :lgetexpr. I'd argue that running QuickFixCmd* for :lgetexpr
> > > > makes little sense, since :lgetexpr is almost never called run
> > > > interactively. So, was there an actual reason for this change,
> > > > right before the release of Vim 8?
> > >
> > > Can you give more details about what breaks? The autocommands are
> > > there to allow plugins to deal with changes in the Quickfix list.
> > > I hope it's not actually being used for something else.
> >
> > As I said in another message, people do thinge like this:
> >
> > if has('autocmd')
> > augroup Ferret
> > autocmd!
> > autocmd QuickFixCmdPost [^l]* nested cwindow
> > autocmd QuickFixCmdPost l* nested lwindow
> > augroup END
> > endif
> >
> > This is fine for opening grep windows automatically and what
> > not, but the loclists created by things like lgetexpr are typically
> > parsing in progress, and are never meant to be displayed at that
> > stage. Plugins calling lgetexpr are now all of a sudden calling
> > autocmds from unrelated plugins.
> >
> > As Christian Brabandt points out, this can be prevented by
> > doing something like "noautocmd lgetexpr ...", and thus fixing
> > something that was never broken. Or it can be prevented by adding
> > a more restrictive pattern in autocmd QuickFixCmd<mumble>, and thus
> > avoiding a pitfall that didn't exist before 7.4.2299. _shrug_
>
> I would say that you have just been lucky that the way the quickfix
> list was created didn't trigger an autocommand. These Ferret
> autocommands just do what they are supposed to do: open a quickfix
> window when there is a quickfix list. And syntastic creates a
> quickfix list, thus it works as intended.
These Ferret autocommands shouldn't mess with quickfix lists created
by other plugins. Sadly, the QuickFixCmd* autocommands have no way
to tell what created the lists they act on, nor is there any way for
applications to pass them this information. Recent versions might use
the new title field for that purpose, but that feature is only a few
weeks old, it can't be relied on for the next year or so.
> Why is it that the quickfix list that syntastic creates must not be in
> a quickfix window?
Because it's just an intermediate result that needs to be massaged
before it can be usefully displayed. Some linters produce simple-minded
error messages:
foo.c:33:7: Error: "bar" not found, oh what to do, what to do!
These messages can be parsed with a single line of errorformat,
and everybody lives happily ever after. Other linters however are a
lot more creative than that. For example they might produce 0-based
line numbers while Vim wants them 1-based, so the numbers need to be
adjusted. Line numbers might point beyond the file's end, and they also
need to be adjusted. Messages might have a different encoding than the
current one (hello, Haskell) and they need to be converted. They might
contain XML entities that need to be decoded. Invalid errors need to be
purged. Some other errors need to be removed because the user doesn't
care to see them. The list might need to be re-sorted. Other things
might need to be normalised, fixed, or otherwise transmogrified. And so
on, and so forth. The bottom line is, the result of :lgetexpr is not
directly usable, it needs to be processed first.
Unrelated, syntastic has a mode where it tries not to mess with the
current loclists, to minimise conflicts with third-party plugins. In
that mode the list is copied elsewhere and the original is discarded
with :lolder. It never displays the list in a window.
(On a side note: :lolder, :lnewer and friends still don't trigger
the QuickFixCmd* autocommands. I presume the very same people that
asked for :lgetexpr to trigger them will hurry to make a case for adding
autocommands to :lolder etc. too, in the name of further consistency.)
Normally :lgetexpr shouldn't be used for parsing error messages like
this. If Vim regexps had named subexpressions as other languages, all
the errorformat horrors could have been avoided and parsing would go
something like this:
while(<>) {
...
m/^(?<fname>[^:]+):(?<lnum>\d+):(?<col>\d+): (?<type>[EW])(?:rror|arning):
(?<text>.+)/;
...
}
This would be substantially better than errorformat & Co. because
the enclosing loop would be under user's control. So lines could be
joined etc. when the _context_ requires it before trying to parse
anything. This is where Emacs wins big over Vim.
Even with the current Vim regexps, syntastic using errorformat
has been a mistake, in my opinion. I suppose the original author of
syntastic just started with the simple cases, and using the "official"
Vim functions to parse errors was the obvious choice.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
