I have the following problem in gvim (Huge) 7.4.1087. My previous
build was 7.4.1074 and IIRC it did not have this problem. Between them
I notice several patches affecting Ctrl-A and Ctrl-X in Visual mode,
or in RTL mode, or with '[ and '] marks, none of which seem to apply
to my usecase. I am using Ctrl-A in plain Normal mode and repeating it
with . (in the {rhs} of a mapping). Trying to find out what went
wrong, I found that apparently _neither_ . _nor_ mappings (nor "q"
macros) properly repeat Ctrl-A nowadays:
• If the latest change was a Ctrl-A (increment), the . (dot) command
now does not repeat it, but any previous insertion. Now i<Esc> then
any number of Ctrl-A interspersed with movements: if I hit . it does
nothing (it used to repeat the latest increment with its count, now it
repeats the i<Esc> which is a null insertion).
• After the following:
:nnoremap <S-F1> j2<C-A>
if I hit Shift-F1 one line above a number, that number won't be
incremented. (I would have expected it to be incremented by 2).
• If I do
qqj2^Aq
where ^A means "hit Ctrl-A" the q register contains a strange sequence
of bytes, and @q goes down by one line but does not increment the
number found there.
I used to have a mapping
map <S-F1> j.
which, when executed after a Ctrl-A, would go down one line and repeat
the same increment there. Now that mapping still goes down one line,
does some strange lateral movement, sometimes by one column and
sometimes not (in a file in us-ascii with no hard tabs) and does not
increment. If before the Ctrl-A I had made an edit in Replace mode,
what is repeated is now the Replace-mode insertion instead of the
Ctrl-A as I had expected.
Explanation: In that file there is a column of lines where, at some
point horizontally, there is a column containing successively higher
numbers (1,2,3, ..., 475) on successive lines. If I move a number of
lines to different positions I want to renumber the rest. So I would
edit the first displaced line, then do a Ctrl-A (with implicit count
of 1) on the next line, then hit Shift-F1 (remapped to j.) repeatedly
to increment (by 1) all successive lines until the next displaced one.
Edit that. Do 2 Ctrl-A to the line after that. Hit Shift-F1 repeatedly
to increment the following lines by 2. And so on.
But that was until yesterday (or maybe the day before). Now this
usecase is completely broken due to the fact that . does not take any
Ctrl-A (or presumably Ctrl-X) change into account, but only the last
change before that. Yet Ctrl-A is still a "change" or has that
recently been changed?
N.B. No register involved and no Visual mode.
Regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
