search

tpope / vim-unimpaired

unimpaired.vim: Pairs of handy bracket mappings
https://www.vim.org/scripts/script.php?script_id=1590
3.31k stars 205 forks source link

Add support for cabove/cbelow #195

Open bo5o opened 4 years ago

bo5o commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

: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 commented 4 years ago

@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 commented 4 years ago

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 commented 3 years ago

cf. #133

hoclun-rigsep commented 3 years ago

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

tpope commented 3 years ago

I've been contemplating something like this:

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.