[vim/vim] `QuickFixCmdPre` and `QuickFixCmdPost` are not triggered after `colder`, `cnewer`, `chistory` and friends (Issue #11584)
bfrg
Steps to reproduce
I'm not sure whether to mark this as a bug or a feature request. The QuickFixCmdPre and QuickFixCmdPost events are not triggered when running colder, cnewer, chistory, lolder, lnewer and lhistory.
Were these command left out deliberately or were they just forgotten? Would there be any side effects if they were added to the list of other quickfix commands that trigger the above events?
Maybe it would be better to add two new events, like QuickFixHistoryPre and QuickfixHistoryPost, where the pattern is matched against the command that triggered the change, i.e. colder, lolder etc.?
Expected behaviour
I think it would be helpful to have an event that is triggered when the quickfix or location-list stack is accessed.
Version of Vim
9.0.900
Environment
Linux
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### Steps to reproduce
>
> I'm not sure whether to mark this as a bug or a feature request. The
> `QuickFixCmdPre` and `QuickFixCmdPost` events are not triggered when
> `lhistory`.
>
> Were these command left out deliberately or were they just forgotten?
making the quickfix/location list and to possibly change it before
jumping to the first location. Moving through the older/newer lists
does not need that, the lists were already created and should not be
changed.
> Would there be any side effects if they were added to the list of other
> quickfix commands that trigger the above events?
>
> Maybe it would be better to add two new events, like
> matched against the command that triggered the change, i.e. `colder`,
> `lolder` etc.?
>
> ### Expected behaviour
>
> I think it would be helpful to have an event that is triggered when the
> quickfix or location-list stack is accessed.
From a high level view: This handling of the quickfix and location lists
is already very complex. I rather only make changes when there is a
good motivation, when something is not currently possible. Just adding
things for consistency or it seems like a good idea is risking to break
something, or adding code that won't be used.
--
Common sense is what tells you that the world is flat.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
The QuickFixCmdPre and QuickFixCmdPost are intended to prepare for
making the quickfix/location list and to possibly change it before
jumping to the first location. Moving through the older/newer lists
does not need that, the lists were already created and should not be
changed.
Okay that makes sense.
What would we need QuickFixHistory* events for?
I have a plugin that highlights the quickfix locations using signs and text-properties. Think of highlighting compile errors in the quickfix list. The plugin can also display the error messages using virtual text right next to the line containing the error. It always uses the current quickfix list and/or current location-list of the current window. Now I wanted to automatically update the signs and text-properties when changing to another quickfix list in the stack with :colder, :cnewer or :chistory [N].
I don't think there are a lot more use cases for an event like QuickFixHistory. For my plugin this wouldn't even be enough. Ideally, I would also need a QuickFixChanged event that is triggered when a quickfix list is changed through setqflist(), for example like :Cfilter does it, in order to automatically remove old highlightings.
Anyway, since this is too special, I'm closing this issue.
Screenshot what it looks like with signs, text-properties and virtual text:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
Closed #11584 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Nick Jensen
Another use case would be for formatting and presenting the quickfix/loclist window nicely. Plugins like vim-qf have a feature that opens the quickfix window to a height that matches the number of entries, when that number is less than e.g. 10. So when there are 3 items in the quickfix list, the window will be 3 lines high. :colder/:cnewer don't currently trigger any autocmds so to update the window height a wrapper script must be maintained. However a QuickFixHistoryPost autocmd would make this much simpler.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > What would we need QuickFixHistory* events for?
>
> I have a plugin that highlights the quickfix locations using signs and
> text-properties. Think of highlighting compile errors in the quickfix
> list. The plugin can also display the error messages using virtual text
> right next to the line containing the error. It always uses the
> window. Now I wanted to automatically update the signs and
> text-properties when changing to another quickfix list in the stack with
>
> I don't think there are a lot more use cases for an event like
> I would also need a `QuickFixChanged` event that is triggered when a
> quickfix list is changed through `setqflist()`, for example like
> `:Cfilter` does it, in order to automatically remove old highlightings.
current quickfix list. It would not matter how they got changed, by a
command, function, anything.
There are two things: The list of locations and the current position.
I guess using two separate events should work:
QuickfixList when any entry in the current list changes
QuickfixPosition when selecting another entry
--
hundred-and-one symptoms of being an internet addict:
103. When you find yourself in the "Computer" section of Barnes & Noble
enjoying yourself.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
Aha, so you don't actually care about the commands, you care about the
current quickfix list. It would not matter how they got changed, by a
command, function, anything.
Exactly.
There are two things: The list of locations and the current position.
I guess using two separate events should work:QuickfixList when any entry in the current list changes
QuickfixPosition when selecting another entry
I'm not sure I understood you correctly. What I meant was one event that is triggered when an older/newer quickfix list in the stack is selected (using :colder or similar), and another event when one particular quickfix list was changed, i.e. when its changedtick is incremented (this occurs when setqflist() is called, or with :vimgrepadd, :caddexpr and friends).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > Aha, so you don't actually care about the commands, you care about the
> > current quickfix list. It would not matter how they got changed, by a
> > command, function, anything.
>
> Exactly.
>
> > There are two things: The list of locations and the current position.
> > I guess using two separate events should work:
> >
> > QuickfixList when any entry in the current list changes
> > QuickfixPosition when selecting another entry
>
> that is triggered when an older/newer quickfix list in the stack is
> selected (using `:colder` or similar), and another event when one
> particular quickfix list was changed, i.e. when its `changedtick` is
> incremented (this occurs when `setqflist()` is called, or with
What would you do differently? Assuming a call to setqflist() is used
then any of the entries can change. Isn't this so similar to switching
to an older or newer list that it would be handled the same way? At
least when you update info associated with the entries I would think
exactly the same happens.
When changing to an older or newer quickfix list, I wonder if you do
something with that, e.g. showing "list 5 of 10" in some way. I don't
actually see a way to get that index, other than using :chistory and
parsing the output.
--
Corduroy pillows: They're making headlines!
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Nick Jensen
When changing to an older or newer quickfix list, I wonder if you do
something with that, e.g. showing "list 5 of 10" in some way. I don't
actually see a way to get that index, other than using :chistory and
parsing the output.
echo getqflist(#{nr:0}).nr .. ' of ' .. getqflist(#{nr:'$'}).nr
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
What would you do differently? Assuming a call to setqflist() is used
then any of the entries can change. Isn't this so similar to switching
to an older or newer list that it would be handled the same way? At
least when you update info associated with the entries I would think
exactly the same happens.
Yes, you're right. For my use case it wouldn't matter how the quickfix list changes.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.