Skip to content
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

Support count for <Plug>(qf_qf_previous) and friends #95

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

olmokramer
Copy link

@olmokramer olmokramer commented Dec 31, 2019

A count was ignored for (qf_qf_previous), (qf_qf_next), (qf_loc_previous), and (qf_loc_next). This is a rather simple implementation, and thus may not yet behave entirely as expected.

The count is only passed on to :[cl]previous and :[cl]next, but it is ignored when we wrap using :[cl]first and :[cl]last. So 100<Plug>(qf_qf_previous) while at the top of the list will only jump to the end, not to the 100-to-last item in the list.

Also, :[cl]previous and :[cl]next do not throw when the count is greater than the number of items moved, e.g. :3previous while on the 2nd entry in the list will move to the 1st entry, so it doesn't wrap in that case.

I think both of these limitations are acceptable, but I'll gladly implement something a bit more complex to handle these cases. Wanted to check with you first, though, before doing unnecessary work.

TODO:

  • Update documentation.

A count was ignored for <Plug>(qf_qf_previous), <Plug>(qf_qf_next),
<Plug>(qf_loc_previous), and <Plug>(qf_loc_next). This is a rather
simple implementation, and thus may not yet behave entirely as expected.

The count is only passed on to `:[cl]previous` and `:[cl]next`, but it
is ignored when we wrap using `:[cl]first` and `:[cl]last`. So
`100<Plug>(qf_qf_previous)` while at the top of the list will only jump
to the end, not to the 100-to-last item in the list.

Also, `:[cl]previous` and `:[cl]next` do not throw when the count
is greater than the number of items moved, e.g. `:3previous` while on
the 2nd entry in the list will move to the 1st entry, so it doesn't wrap
in that case.

I think both of these limitations are acceptable, but I'll gladly
implement something a bit more complex to handle these cases. Wanted to
check with you first, though, before doing unnecessary work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant