Skip to content
This repository was archived by the owner on May 1, 2022. It is now read-only.

Tags: inkarkat/vim-repeat

Tags

archive/compat-fix-feedkeys-order

Toggle archive/compat-fix-feedkeys-order's commit message
feedkeys(..., 'i') sends keys in the wrong order in Vim 7.0/1/2

The current implementation prefers feedkeys(..., 'i') and only falls back to :normal if Vim 7.4 does not have the 'i' flag and if Vim 7.3 supports :normal with count. For Vim 8.0 (and later), and also for versions between 7.0 and 7.3.99, feedkeys(..., 'i') is used. Due to the prepending action of the 'i' flag, keys must be submitted in reverse order; that's why s is submitted before r . cnt.  Vim 7.0...7.3.99 ignore the 'i' flag, though, and append the keys, which are now in the wrong order (this only matters if a register or count is given).

Add a separate conditional branch for Vim versions before 7.3.100 that uses feedkeys() in the correct order and omits the ignored 'i' flag.

archive/register-override

Toggle archive/register-override's commit message
Make an explicit register on repeat override g:repeat_reg

As with built-in commands, this allows to override the original register on repeat, e.g. "a. uses register a instead of the original one.

One limitation is that we cannot detect whether no or the default register has been given, so an override from a non-default to the default register (e.g. via "".) is not possible.

archive/prefer-normal

Toggle archive/prefer-normal's commit message
Always send register without remapping

archive/avoid-unmodifiable-function-error

Toggle archive/avoid-unmodifiable-function-error's commit message
Avoid function error when buffer is not modifiable

When the buffer is unmodifiable, all wrapped commands cause:

Error detected while processing function <SNR>42_wrap:
line 2:
E21: Cannot make changes, 'modifiable' is off

instead of just the error message in the last output line.

To avoid that, check for this condition in the wrapper mapping, and force the E21 by directly executing the wrapped command. The only downside is that this doesn't also handle a W10 readonly warning in the same way.

v1.2

Toggle v1.2's commit message

Verified

This tag was signed with the committer’s verified signature.
tpope Tim Pope
repeat.vim 1.2

* Provide <Plug> mappings.
* Enable repeating operators with custom motions.
* Assorted bug fixes.

v1.1

Toggle v1.1's commit message

Verified

This tag was signed with the committer’s verified signature.
tpope Tim Pope
repeat.vim 1.1

archive/doc-update-for-setreg

Toggle archive/doc-update-for-setreg's commit message
Documentation fix for repeat#setreg()

Need to :execute the :silent! call to avoid that the remainder of the
command line is aborted together with the call when repeat.vim is not
installed. Otherwise, <SID>MyFunction() won't be invoked, and the
mapping does nothing.

archive/full-customizability

Toggle archive/full-customizability's commit message
Allow customizing all mappings

f1d0fbb allowed customizing the .
mapping by making the implementation function publicly accessible. Let's
do the same to s:wrap(), so that the other mappings (u, U, <C-R>) can be
extended, too.

(Personally, I'd like to have undo / redo stop and beep at the last
saved position, to avoid that I accidentally undo beyond the saved state
even though I didn't intend to.)

archive/no-feedkeys

Toggle archive/no-feedkeys's commit message
Remove feedkeys() to aid remapping

archive/no-forced-modify

Toggle archive/no-forced-modify's commit message
Don't increment b:changedtick, offer invalidate instead

repeat#set() so far automatically incremented b:changedtick. Problems
with this:
1. The way that was done clobbered the expression register "=.
2. It causes the "readonly" warning and "Cannot make changes" error in
   readonly/nomodifiable buffers, so mappings that don't modify anything
   cannot be repeated there.
3. It's actually not needed most of the time, because many user mappings
   and all repeatable Vim built-in normal mode commands I know (with the
   exception of yank with cpo+=y) actually do modify the buffer
   themselves.

For the exceptional case where the user has a set of related mappings,
one that repeats naturally (e.g. a custom operator, via g@), and one
that invokes repeat#set(), and both do not modify the buffer, a new
function repeat#invalidate() is offered. This should be called by the
former mapping, and all is well.