remappings in autoload

[Konfekt]

If vim-repeat would define its functions in /autoload and mappings in /plugin then keys overriden by vim-repeat could be remapped in .vimrc (for example <ctrl-r>).

This way, the first call of repeat#set() will override those keys overriden by vim-repeat. This happens for example the first time the user uses a mapping made repeatable by vim-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 artifical silent! call repeat#set("\<key>",1) before these mappings is no longer needed (which also defeats the autoload functionality).

This relates to https://github.com/tpope/vim-repeat/issues/22 and https://github.com/tpope/vim-repeat/issues/19

[tpope]

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.

[Konfekt]

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.

[tpope]

Wait, ignoring everything else, how does moving them to a plugin solve anything? Plugins still load after your vimrc.

[Konfekt]

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?

[Konfekt]

For short, if vim-surround used <plug>... mappings, and only if <plug>... is not already mapped, then overriding would be more convenient.

[tpope]

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:

• Manual installations still happen. Even I occasionally do it, on servers without Git for example. Not a big deal, as I said, but still a small advantage of the current setup.
• When you're talking about a 128 line file, the "point of autoload" (by which I assume you mean quicker startup) is basically negligible.
• Reasons the 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.