Add support for cabove/cbelow

[bo5o]

Recent versions of vim include :cabove and :cbelow (and loclist equivalents) to move to quickfix item above and below the current cursor position (see this PR in vim/vim)

Maybe mappings for those would be a nice addition to this plugin.

[tpope]

These are cool but I'm not sure where they would fit. It's tempting to swap them out for :cnext and :cprevious but I think it's a bit too soon for that.

[jeffvandyke]

:cabove and :cbelow apparently aren't in Neovim yet, might take a few weeks.

Also personally, I find the [q and ]q work very nice when the quickfix spans multiple files, and I can't confirm that :cbelow for instance goes to the next file if we're at the bottom, and would really want navigation between files to work somehow.

[bo5o]

@tpope I've been thinking the same.

:cabove/:cbelow don't work in some situations yet. For example in fugitives :Glog you still need :cnext/:cabove to navigate the list and there is more situations like that.

Currently I have mapped them to [d/]d (the mnemonic is 'next/previous diagnostic', because I mostly use it to navigate through linter warnings and errors for current file). Maybe this a common use case.

@jeffvandyke It has been merged into neovim 0.5.0 pre-release (see this commit)

[tpope]

If it's scoped to the current file then yeah, we probably shouldn't replace the existing mappings. Linter warnings is also my use case, but that means :labove and :lbelow, which is a bit of an odd thing for Unimpaired to express a preference on.

[hoclun-rigsep]

cf. #133

[hoclun-rigsep]

Am I the only one confused about the need for both :cabove and :cbefore?

[tpope]

I've been contemplating something like this:

• [q = :cbefore
• ]q = :cafter
• [Q = :cpfile
• ]Q = :cnfile
• <q = :cprevious
• >q = :cnext
• =q = :cc
• <Q = :cfirst
• >Q = :clast
• =Q = :copen / :cclose (or whatever)

By shuffling :cnext and :cprevious over to <q and >q, that gives us =q as an intuitive place to stick :cc, which is something I've wanted for a while. Or we could favor backwards compatibility over intuition and use </>/= for the new behaviors, that wouldn't be the end of the world. Either way we'd get 3 new maps and solve the <C-Q> problem to boot, nice.

This problem is the location list variants. >l is technically a valid operation, though it's identical in behavior to >> since > is always lineways. >L, on the other hand, is a valid operation with no other equivalent. It's a weird operation that I would expect virtually no one to use, but I don't think "weird" is enough of justification to shadow.

And if we want the ] and > maps to match up, all of o, c, a, t, i, o (again), and n are taken on one side or the other. The least worst option might be moving the [o and ]o option togglers again. I'm sure people would love that. Or if we give up on the mnemonic, we could move [y and ]y, as those are a bit more niche.

So I guess as a first step, I am adding [C and ]C aliases for [y and ]y, and we'll see if those get any push-back.

Am I the only one confused about the need for both :cabove and :cbefore?

The difference is "current line" versus "exact cursor position". Barely seems worth bothering with but I guess it doesn't hurt anything.