Ingo Karkat wrote:

> On 06-Jan-2011 11:37, ZyX wrote:
> > Reply to message «Why does ':normal' ignore the 'count' prefix for mapped 
> > keys?», 
> > sent 08:00:58 06 January 2011, Thursday
> > by Douglas A. Augusto:
> > 
> > It looks like a bug and so must be forwarded to vim-dev mailing list. By 
> > the 
> > way, everything works with feedkeys:
> > 
> >     vim -u NONE -c 'redir! > messages' \
> >                 -c 'execute "fu E(str)\nechom a:str\nretu \"\"\nendf"' \
> >                 -c 'noremap <expr> _x E(v:count)' \
> >                 -c 'normal 3_x' \
> >                 -c 'call feedkeys("3_x:\<C-u>qa!\n")'
> > 
> > and you will get 0 and 3 in ./messages. Tested on vim-7.3.75 from gentoo 
> > repos 
> > and 7.3.98 (revision 763272b18e4f).
> > 
> > Original message:
> >> Suppose I've created the following map:
> >>    :map _x :<C-U>echo "v:count=".v:count<CR>
> >>
> >> In normal mode I type
> >>    2_x
> >> and it prints
> >>    v:count=2
> >>
> >> But in command-line mode if I enter
> >>
> >>    :normal 2_x
> >>
> >> it prints
> >>    v:count=0
> 
> I encountered this, too, and it severely impacts automated testing of Vim
> plugins. (I was hit by this recently, sorry that I didn't yet report it; I'm
> glad that the example mapping from Douglas shows the problem so succinctly.)
> 
> I'm using my runVimTests framework
> (http://www.vim.org/scripts/script.php?script_id=2565) to test-drive my 
> plugins,
> and naturally invoke mappings with :normal, and then typically check the text
> modifications via getline(). Using feedkeys() is no alternative in this case,
> because these keys are only processed after the driving Vim test function
> returns, so the getline() within that function that aims to verify the mapping
> finds that the mapping hasn't yet run, and that there are no modifications! I
> had to use very ugly workarounds (manually setting g:count, and using that in 
> my
> plugin) to get mappings with <count> tested at all!
> 
> In general, I try to avoid feedkeys() in mappings, because I found that it 
> also
> doesn't play well with recorded macros (those keys are processed out-of-order 
> at
> the end of the macro).
> 
> I really hope that the :normal <count> issue can be fixed, as this is a
> showstopper for automated tests.

It's easy enough to change:

--- ../../vim-7.3.098/src/ex_docmd.c    2010-12-02 16:01:23.000000000 +0100
+++ ex_docmd.c  2011-01-06 17:23:43.000000000 +0100
@@ -9310,7 +9310,7 @@
                                                                  && !got_int)
     {
        update_topline_cursor();
-       normal_cmd(&oa, FALSE); /* execute a Normal mode cmd */
+       normal_cmd(&oa, TRUE);  /* execute a Normal mode cmd */
     }
 }
 #endif


I wonder what trouble this would cause.

-- 
>From "know your smileys":
 :-)-O  Smiling doctor with stethoscope

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
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

Raspunde prin e-mail lui