Closed GoogleCodeExporter closed 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
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:
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
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:
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
Original issue reported on code.google.com by
jke...@connectwise.com
on 2 Apr 2014 at 8:44