-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lines appended to QuickFix list are not seen (e.g., from async Grepper) #25
Comments
In theory it might be possible to add support for asynchronously added quickfix entries to quickfix-reflector. Some thoughts on that:
You already suggested a workaround. That should work. The scrolling problem can be avoided like this:
quickfix-reflector does the same thing when you save the qf buffer. I'll add a note to the documentation. |
Thanks for the idea to save and restore the winview; that works well. I've incorporated it into my grepper patch. Grepper uses |
The QuickFix Reflector relies on
BufReadPost quickfix
autocommands to signal changes to the QuickFix list. Unfortunately, these autocommands are not generated when appending to an existing non-empty list. This causes no problems for commands like:grep
, where the entire output is written into the list at once before generatingBufReadPost
; but when the output is written piecemeal using:caddexpr
, such as by an asynchronous search plugin like Grepper (https://github.com/mhinz/vim-grepper), only the first set of lines to be written will generateBufReadPost
, leaving QuickFix Reflector unaware of any subsequent changes. The problem does not occur when the QuickFix list window is not open until after the list is finalized, and the problem can be fixed by closing and reopening the QuickFix window.Unfortunately, I don't see a good way to correct this in QuickFix Reflector itself. I'm currently experimenting with a patch in the Grepper plugin to re-write the entire QuickFix list upon completion of the search using
setqflist(getqflist())
(see patch below). This generates one finalBufReadPost
autocommand to avoid the above problem. This work-around has a drawback for slow searches, however; if the user has time to interact with the partial results in the QuickFix window, he may find it unsettling when the call tosetqflist()
resets the list and scrolls the QuickFix window back to the start. Also, a similar fix would be required for every other source of QuickFix data that gets delivered in pieces.In any event, it might be worth adding something the QuickFix Reflector's documentation describing this problem and some possible work-arounds. I believe this is the underlying problem that @Konfekt was seeing in #22.
The problem can be demonstrated without Grepper as follows:
f.txt
with these two lines:Edit the file via
vim f.txt
.Execute these Vim commands:
The
:w
triggers a long series of exceptions caused by addinga line to the list via
:caddexpr
. To demonstrate thework-around, execute
:call setqflist(getqflist())
after the:caddexpr
and the:w
will then work.Here is the grepper patch to work around this issue:
The text was updated successfully, but these errors were encountered: