0

Specifically, I'm looking to bind the search /\(<<<<\|====\|>>>>\)/ (i.e. "find the next git merge boundary"). Ideally to <C-/> or <A-/>, but that part I'm not picky about.

I have tried

nmap <A-/> /\(<<<<\|====\|>>>>\)/<CR>
nmap <C-/> /\(<<<<\|====\|>>>>\)/<CR>
nmap <C-/> /\(<<<<\|====\|>>>>\)<CR>
nmap <C-/> :/\(<<<<\|====\|>>>>\)/<CR>

None of them work. The two <C-/> did nothing, and the version with <A-/> started a normal search. I also tried with a simpler search (a literal string) to make sure this wasn't a malformed query issue, for most of these cases.

LastKopek
  • 3
  • 1

2 Answers2

1

Rather than rolling your own mappings for this purpose, I'd recommend adopting the excellent vim-unimpaired plug-in, which defined two specific mappings for this purpose:

[n                      Go to the previous SCM conflict marker or diff/patch
                        hunk.  Try d[n inside a conflict.

]n                      Go to the next SCM conflict marker or diff/patch hunk.
                        Try d]n inside a conflict.

There are a few advantages to using a plug-in such as vim-unimpaired for these mappings:

  • The patterns have been fine tuned to recognize exactly the conflict markers, by looking at exactly 7 characters (<, = or >) and always at the beginning of the line. The vim-unimpaired mappings also recognize other markers typically found in patch or diff files, which makes it useful.
  • You get mappings for both directions, ]n to go to the next conflict markers, [n to go to the previous one.
  • The mappings work well with operators. For example, you can use d[n inside one branch of the conflict to delete that branch, in cases where you intend to keep the other one. Vim has a few commands that use the [ and ] prefixes to move to a previous or next occurrence of a character or pattern, such as [{ for the previous opening bracket, or ]m for the next method definition in languages like Java.
  • By using a popular plug-in, you'll benefit from all the testing and fixes to ensure it works well and covers corner cases you might not have thought of or encountered.
  • You get many more useful mappings. The vim-unimpaired mappings take the [ and ] idea further, by defining many other pairs of useful mappings to locate or move to previous and next elements of other kinds.

So I'd suggest you take that into consideration when looking for an easier way to navigate conflict markers.

Regarding the issues you encountered when trying to implement your mappings:

  1. Not all combinations using the Ctrl key are possible in Vim. See, for example, this answer which explains it in some more detail. There are sometimes platform differences (depending on your O.S., on whether you're running Vim on a terminal or a GUI version of Vim), but some key combinations are definitely problematic.
  2. In a map command, the bar | is special and needs to be escaped with a backslash. Since you also need one for the pattern, you need more than one here. (I think you need three, but it's possible that two might work.) You can look at :help :bar for some more details.
filbranden
  • 28,785
  • 3
  • 26
  • 71
  • 1
    I don't think Ingos answer is still completly correct nowadays, at least if you use xterm with modifyOtherKeys. See also the faq: https://vimhelp.org/vim_faq.txt.html#faq-20.5 I think there are also other answers here that mention this. – Christian Brabandt Dec 03 '20 at 08:43
  • I avoid plugins where possible. And "many more useful mappings" is a bug, not a feature; mappings I don't know about are obstacles which cause mysterious failures. – LastKopek Dec 03 '20 at 16:54
  • While I don't disagree with the general sentiment ("more plug-ins is not necessarily better", and a minimalist approach is good), there are some plug-ins that are definitely worth it and this is one of them (vim-surround is the other one.) The mappings provided by vim-unimpaired are not bloat, they're well though shortcuts for common and useful operations. One might even say that the mappings in these two plug-ins (and perhaps a couple others) might even have been Vim built-ins, so well thought and seamless they are. – filbranden Dec 03 '20 at 18:18
  • Ultimately it's up to you to decide whether you want to adopt a plug-in or not... But make sure you also consider that adding a bunch of custom mappings to your vimrc can also quickly become bloat, as they tend to bit rot, you forget about them (or why you added them in first place) and they start interfering with other stuff. It's also hard to get things right in Vimscript, so leveraging the experience of others has a lot of value here. I definitely stand by my advice, but like I said, it's up to you to decide what's right for yourself. – filbranden Dec 03 '20 at 18:21
  • I have monitoring set up to detect which mappings I use. It's most of them, but if there's one that I haven't used in six months, I will see that fact and prune it. And in any case, a stray mapping I created and forgot about is self-inflicted. I'm not going to let someone else inflict dozens on me all at once. – LastKopek Dec 04 '20 at 17:56
1

When I try your mapping for <C-/> nothing happens for me either. I've also had my own issues when I wanted to use <A-/> as well. As @b-layer and @filbranden pointed out, there are certain key combinations that are difficult to map, if not impossible. If you need more mapping key combinations, @b-layer referenced how to set up mapping the Alt key combinations as <A- > in his comment.

If the mapping itself isn't a deal breaker, I modified your mapping to:

nmap <C-l> /<<<<\\|====\\|>>>><CR>

I deleted the \( and \) because I didn't need to create the search arguments as custom atoms, it worked without them.

@filbranden also explains that the search string needs the escaped pipe, and the mapping needs to escape the backslash so the pipe can be properly escaped.

Hope this helps!

Vee
  • 338
  • 2
  • 13