Am 16.10.2012 21:34, schrieb Christian Brabandt:> Andy, Ben,
On Mi, 03 Okt 2012, Christian Brabandt wrote:
On Di, 02 Okt 2012, Ben Fritz wrote:
gvim -N -u NONE -i NONE
Set up some sample text:
10aone two three<CR><Esc>
Press gg to get the cursor at the top of the buffer.
Perform a search:
/two<CR>
Change text:
cgnduo<Esc>
Do it again, 3 times:
...
Expected result:
one duo three
one duo three
one duo three
one duo three
one two three
one two three
one two three
one two three
one two three
one two three
Actual result:
one duo three
one dududuoee
one two three
one two three
one two three
one two three
one two three
one two three
one two three
one two three
Vim version:
Yes, that is a known problem (see
https://groups.google.com/group/vim_dev/msg/b3532b18a40b0bcb), but I am
not sure, how to get around this.
Could you please test, if the attached patch works for you?
I don't fully understand the redo stuff buffer. So I am not sure, if
this is the correct way to test, whether the input comes from the stuff
buffer, but for my simple test case, this seems to work ok.
The cursor-not-at-start-of-match problem seems to be fixed.
I can place the cursor within a match and `.' works (after `dgn'),
several times, as long as there is a match.
('wrapscan' is off)
But ...
when there are no more matches (= when the cursor is beyond the last match),
`.' makes the cursor change its shape (as if it waits for something [1])
but it correctly beeps.
repeating `.' then deletes arbitrary text ...
Something is still wrong, it should just beep and don't do anything.
FYI: I applied the patch to gVim 7.3.666
[1] the same shape appears when typing a count after the operator
--
Andy
--
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
