tpope / vim-repeat

repeat.vim: enable repeating supported plugin maps with "."
http://www.vim.org/scripts/script.php?script_id=2136
2.58k stars 81 forks source link

Add g:vim_repeat_default_mappings setting to control mappings. #72

Closed infokiller closed 5 years ago

tpope commented 5 years ago

I can merge something like this if you really need it, but given the way lazy loading works as discussed in #70, I think you'd be better off unmapping in after/autoload/repeat.vim and then remapping whatever you want.

infokiller commented 5 years ago

Apologies in advance for any stupid questions stemming from my shitty vim script skills... Isn't it cleaner to add the option for the plugin to prevent rebinding keys, instead of always rebinding and then unbinding?

tpope commented 5 years ago

The thing that makes this different from most plugins is that ideally you'll define your custom maps in after/autoload/repeat.vim rather than your vimrc, in order to benefit from lazy loading. And since you have to create that file anyways, calling unmap a couple of times is no big deal.

But if you really want it, change the conditional to !get(g:, 'repeat_no_maps') (to match my other plugins) and I'll merge.

infokiller commented 5 years ago

Why do I have to create the after/autoload/repeat.vim file anyways? do you mean that I need to do it when customizing the key mappings (in contrast to a more regular usage of the plugin)?

One advantage that I see of having the repeat_no_maps setting as a user is that you don't have to worry about the exact remappings done by the plugin. You just define what you need. Without this setting, the user needs to read the source (or check :map after the plugin is loaded) to get the complete list of mappings done by the plugin, and then manually unmap each one. And in principle, this should be done every time the plugin is updated.

tpope commented 5 years ago

Why do I have to create the after/autoload/repeat.vim file anyways? do you mean that I need to do it when customizing the key mappings (in contrast to a more regular usage of the plugin)?

Yes, when customizing the key mappings.

One advantage that I see of having the repeat_no_maps setting as a user is that you don't have to worry about the exact remappings done by the plugin. You just define what you need. Without this setting, the user needs to read the source (or check :map after the plugin is loaded) to get the complete list of mappings done by the plugin, and then manually unmap each one. And in principle, this should be done every time the plugin is updated.

There are 4 maps. There were 4 maps when I released 1.0 over a decade ago. There will always be 4 maps. This generalization does not apply.

I just realized that the hasmapto() checks mean that if you do define maps in your vimrc (negating the autoloading), these maps won't even get defined. What's the reason you need the option?

infokiller commented 5 years ago

Why do I have to create the after/autoload/repeat.vim file anyways? do you mean that I need to do it when customizing the key mappings (in contrast to a more regular usage of the plugin)?

Yes, when customizing the key mappings.

One advantage that I see of having the repeat_no_maps setting as a user is that you don't have to worry about the exact remappings done by the plugin. You just define what you need. Without this setting, the user needs to read the source (or check :map after the plugin is loaded) to get the complete list of mappings done by the plugin, and then manually unmap each one. And in principle, this should be done every time the plugin is updated.

There are 4 maps. There were 4 maps when I released 1.0 over a decade ago. There will always be 4 maps. This generalization does not apply. If that's the case, I'm more comfortable withdrawing this PR.

I just realized that the hasmapto() checks mean that if you do define maps in your vimrc (negating the autoloading), these maps won't even get defined. What's the reason you need the option? I think you're right, or at least I can't recall why I originally needed them...

infokiller commented 5 years ago

Thanks for all the explanations, closing this PR.