Closed Konfekt closed 9 years ago
You can runtime! autoload/repeat.vim
yourself if you want that. Or define your overrides in after/autoload/repeat.vim
. Splitting the file seems like a very tiny gain in override convenience, in exchange for a small loss in installation convenience. I don't think I'm on board.
Thanks for making me aware of after/autoload/repeat.vim
! NB: The keys then have to be remapped twice, in .vimrc
and in after/autoload/repeat.vim
. (The first option runtime! autoload/repeat.vim
defeats the point of autoload
.)
Where is the current gain in installation convenience, would it not remain cd ~/.vim/bundle && git clone git://github.com/tpope/vim-repeat.git
either way (and equally so for all other common installation methods)?
At the same time, the various issues relating to this one as well as kana's fork at https://github.com/kana/vim-repeat show that the loss in user convenience by having to set your mappings in runtime! autoload/repeat.vim
(a solution hardly anybody knows about) is greater than acknowledged.
Wait, ignoring everything else, how does moving them to a plugin solve anything? Plugins still load after your vimrc.
Just checked, true. I put those in a after\vimrc.vim
sourced on VimEnter
.
Still, this would be in compliance with most other plugins, and Joe Schmo knew how to deal with it. One solution would be that vim-repeat
checks for remappings, which it could also do in autoload but only does so for U
. As a compromise, how about mapping all keys by <plug>...
mappings and only if <plug>...
is not already mapped?
My approach was to use
execute 'nnoremap <script> <SID>CtrlR '.(maparg('<C-R>','n') == "" ?
\ '<C-R>' : maparg('<C-R>', 'n'))
nmap U <SID>CtrlR
nnoremap <c-r> <c-l>
in after/vimrc.vim
but then noticed that it fails after the first call of repeat#set(...)
.
I was over-hasty in my enthusiam about after/autoload/repeat.vim
which I considered a sound workaround. Can you check if that works for you? Here it has no effect:
There is nnoremap <C-R> <C-L>
in ~/.vim/after/autoload/repeat.vim
, but :verb nmap <c-r>
shows
n <C-R> * :<C-U>call repeat#wrap("\<C-R>",v:count)<CR>
Last set from ~/.config/.vim/plugged/vim-repeat/autoload/repeat.vim
after repeat#set(...)
. Perhaps a autocmd SourceCmd repeat.vim source <file> | ...
construct is needed?
For short, if vim-surround
used <plug>...
mappings, and only if <plug>...
is not already mapped, then overriding would be more convenient.
You can add the check for remappings if you want. That's still not an argument in favor of splitting out a plugin.
To address other points:
after
technique might fail include cargo culting the include guard, a plugin explicitly calling runtime autoload/repeat.vim
(instead of runtime!
), or a screwed up 'runtimepath'
that puts the after
file before the actual plugin.
If
vim-repeat
would define its functions in/autoload
and mappings in/plugin
then keys overriden byvim-repeat
could be remapped in.vimrc
(for example<ctrl-r>
).This way, the first call of
repeat#set()
will override those keys overriden byvim-repeat
. This happens for example the first time the user uses a mapping made repeatable byvim-repeat
(by a plugin say).How about if
vim-repeat
defines its mappings in/plugin
(like most plugins do) and thus allow the user to map those keys? This way, an artificalsilent! call repeat#set("\<key>",1)
before these mappings is no longer needed (which also defeats theautoload
functionality).This relates to https://github.com/tpope/vim-repeat/issues/22 and https://github.com/tpope/vim-repeat/issues/19