2

After some settings (like installing other plugins and defining some mappings), I've found that GitGutter's Next Hunk (]c and [c) doesn't work any more.

If I do ]cabc I will see :<C-U>execute v:count1 . 'GitGutterNextHunk'<CR>abcin the command, which means the mapping resulted in entering the text in command directly.

When I do :map I see ]c correctly mapped to <Plug>GitGutterNextHunk, which is then mapped as:

n  <Plug>GitGutterNextHunk * &diff ? ']c' : ":<C-U>execute v:count1 . 'GitGutterNextHunk'<CR>"

Btw, calling directly like :execute 'GitGutterNextHunk' works.

This all happens after I added the line set cpoptions="aABceFsd" to my .vimrc. I added the d for tags integration. How may that interfere with my mappings?

Improve this question
2
  • With the new information about cpoptions. seems like you might get a swifter response by asking the plugin creator directly.
    – Rich
    Commented Nov 30, 2017 at 9:43
  • Maybe.. That's interesting though, as I need to do nnoremap / /\\v to achieve what I can do with nnoremap / /\v without the cpoptions settings in my .vimrc...
    – Sunny Pun
    Commented Nov 30, 2017 at 10:12

2 Answers 2

Reset to default
3

From what it looks like GitGutter by default maps <Plug>GitGutterNextHunk and <Plug>GitGutterPrevHunk to ]c and [c respectively. However it will not create the mappings in the following scenarios:

  • Already have mapping to <Plug>GitGutterNextHunk
  • Already have a mapping to ]c
  • Have g:gitgutter_map_keys set to zero

My best guess is that may have already mapped ]c in your vimrc file.

If you wish to debug further then I would recommend using :verbose to see what ]c is mapped to and where the mapping came from, e.g. verbose nmap ]c. Or filtering you mappings via :filter /GitGutter/ nmap

Improve this answer
5
  • Thanks Peter! I have copied this line from GitGutter: :nnoremap <silent> <expr> <Plug>GitGutterNextHunk &diff ? ']c' : ":\<C-U>execute v:count1 . 'GitGutterNextHunk'\<CR>" and I've found that the mapping doesn't work! (<C-U> and <CR> are shown as plain text). I have to remove the ``s to get it working. Is it my setup problem or the plugin's?
    – Sunny Pun
    Commented Nov 30, 2017 at 2:29
  • That line (re-)creates a <Plug>’ mapping. <Plug>` mapping should only be defined by plugins. Remove that line from your vimrc. You want to find out why GitGutter isn’t creating the hunk mappings by default or you want to remap, e.g nmap ]g <Plug>GitGutterNextHunk.
    – Peter Rincker
    Commented Nov 30, 2017 at 2:42
  • Mm.. To clarify, 1. I don't have any related mapping in .vimrc or init.vim.. 2. nmap ]g <Plug>GitGutterNextHunk has the same result as I used ]c: Plain text <C-U> and <CR> 3. Removing the backslashes from the GitGutter line works. I guess the backslashes is causing \<C-U> to be interpreted as plain text. Should I fix the plugin?
    – Sunny Pun
    Commented Nov 30, 2017 at 2:49
  • Please provide a link to your vimrc file or append a snippet of it to your post
    – Peter Rincker
    Commented Nov 30, 2017 at 2:52
  • Thanks Peter, that motivated me to try to reproduce with minimal .vimrc (which I should have thought of before asking, silly me). The issue disappeared after removing set cpoptions="aABceFsd" from my .vimrc. I have modified the question and please see if that line is really the cause of the issue. (If so, please kindly explain)
    – Sunny Pun
    Commented Nov 30, 2017 at 3:28
4

I'm not 100% sure how this is happening, but it's happening because you are setting your 'cpoptions' incorrectly: when using :set to set a string option, you should not enclose the desired value in quotes:

set cpoptions=aABceFsd

As an aside, the documentation for 'cpoptions'recommends that if you just want to add the d flag to the default value, you should use the "+=" feature of set:

set cpoptions+=d
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.