James Vega wrote:
> According to the help, using getchar() in an <expr> map should be avoided:
>
> - You can use getchar(), but the existing typeahead isn't seen and new
> typeahead is discarded.
>
> I'm not sure this limitation is warranted.
>
> A while back, a user in #vim requested the ability to bracket i_Ctrl-r
> with i_Ctrl-g_u so they could more easily undo their changes. My
> immediate suggestion was:
>
> inoremap <expr> <C-r> "\<C-g>u\<C-r>".nr2char(getchar())."\<C-g>u"
>
> This actually works fine, unless you have another mapping that starts
> with the same {lhs}. Using the following mappings (simplified for
> testing):
>
> inoremap <expr> <C-r> nr2char(getchar())
> inoremap <expr> <C-r>xl "foo"
>
> If I press <C-r>xa, I would expect to have xa inserted into the buffer.
> Instead after <C-r>xa, getchar() is waiting for me to type a character.
> So I type y and yxa gets inserted into the buffer.
>
> The xa that I typed to disambiguate the mapping was part of the existing
> typeahead, so when the mapping finally gets triggered it is cached, I'm
> prompted for a character (y) which is pushed onto the typeahead, and
> then the previous typeahead is restored.
>
> If I instead wait for the mapping to timeout, everything works fine, but
> having to wait for the timeout gets pretty annoying.
>
> This same behavior is what was causing the problem ZyX posted[0] about
> some time ago and resulted in this TODO entry:
>
> Cannot use getchar() inside :normal and using an expression mapping. Is =
> this
> supposed to work? (XyX, 2010 Sep 22)
>
> So, I'm not really sure what stashing/restoring the typeahead is
> supposed to protect against. I haven't seen a way to workaround that
> stashing with my map disambiguation example and it seems to cause other
> uses to break even when there aren't ambiguous maps involved. Based on
> that, I propose the attached patch to remove that restriction.
I think the idea at the time was that getchar() should not eat
typeahead. I wonder what breaks if this patch is included.
--
Looking at Perl through Lisp glasses, Perl looks atrocious.
/// Bram Moolenaar -- [email protected] -- 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
