search

javigon / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

feedkeys(".", "n") inside a macro inserts @. register instead of repeating last operation #212

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
If . is mapped to feedkeys(".", "n"), then dot-repeat inside a macro inserts 
the @. register (last inserted text) instead of repeating the previous 
operation. This means that dot-repeat can't be used with macros if Tim Pope's 
repeat.vim[1] plugin is used.

What steps will reproduce the problem?

1. Launch vim as follows:

vim -u NONE -N  -c ':nnoremap . :call feedkeys(".", "n")<cr>'

2. Insert this text in the buffer:

a b c
a b c

3. On the first line, record a macro that performs a dot-repeat:

qqdw.ifoo<esc>

4. On the 2nd line, replay the macro:

@q

What is the expected output? 

fooc
fooc

What do you see instead?

fooc
fofooob c

I have confirmed this issue on at least 4 systems:

  Vim 7.4.183, msys2
  7.4.103, MacVim
  vim.org 7.4.0 build, Windows 7
  Vim 7.3.429, Linux ubuntu 3.2.0-60-generic-pae

---

repeat.vim bug report: https://github.com/tpope/vim-repeat/issues/23

[1] https://github.com/tpope/vim-repeat

Original issue reported on code.google.com by jke...@connectwise.com on 2 Apr 2014 at 8:44

GoogleCodeExporter commented 9 years ago 
Can anyone confirm (or not) this bug? It makes macros less useful, or it makes 
vim-repeat less useful. Having to choose between one and the other is 
troublesome.

Original comment by jke...@connectwise.com on 15 Sep 2014 at 4:20

GoogleCodeExporter commented 9 years ago 
I have looked at the code. The problem is, when using the feedkeys() call, the 
mapped chars will be added at the end of the type buffer, so for the example 
above, this will create the typebuffer of dwifoo<esc>ifoo which is obviously 
not what is wanted.

The attached patch changes it so that when the chars returned by the feedkeys() 
function start with '.' it will be added at the current position rather than 
the end of the buffer.

The patch is also available at:
https://github.com/chrisbra/vim-mq-patches/blob/master/feedkeys_dot

Original comment by chrisbr...@googlemail.com on 16 Jan 2015 at 7:16

Attachments:

GoogleCodeExporter commented 9 years ago 
feedkeys() and macros don't play well together in general. While clever, this 
looks too much like a hack to me; other use cases might want to insert at the 
current typing position, too. I'd rather see an additional parameter to 
feedkeys() that lets the client specify whether to insert at the current 
position or at the end of the type buffer, but that just pushes the complexity 
on to the user, too.

Note: repeat.vim could now use :normal instead of feedkeys; it doesn't do that 
because up to Vim 7.3.100, :normal didn't properly pass on a [count].

Original comment by sw...@ingo-karkat.de on 16 Jan 2015 at 7:26

GoogleCodeExporter commented 9 years ago 
I think another argument for feedkeys would be too complicated. After thinking 
a bit more, I think, when the keys have not been typed, they should always been 
inserted at the current position.
Anybody made the author of repeat.vim aware of the :norm solution?

Original comment by chrisbr...@googlemail.com on 17 Jan 2015 at 1:56

Attachments:

GoogleCodeExporter commented 9 years ago 
I am afraid depending on KeyTyped being true or false is too unpredictable.  
Let's add a flag to feedkeys().  Done in patch 7.4.601.

Original comment by brammool...@gmail.com on 27 Jan 2015 at 2:15