When I first saw the  <expr>  feature, I thought it was a just a
cleaner way of avoiding the :ex interaction in    :call .... <CR> in

     map \a : call Tst()<CR>

Since I'm still not really clear on why there is a difference with
respect to recursion handling, I thought I should ask whether using
the above is still a supported way to implement

1) calling  Tst()  via  \a  to allow  Tst()  to read chars directly
from the user,

while at the same time,

2) calling  Tst()  via
    map \b  \a<key><key><key>
to simulate multiple user key input.


On 4/15/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Eric Arnold wrote:
>
> > I'm not sure what the intended fix for 70d was, but I can no longer
> > send a char to a function indirectly through an <expr> mapping,
> > meaning that in the example below,  \b  does not send a <space>  to
> > Tst().  Tst() waits for input directly from the user.
> >
> > Note:  using
> >     map \a : call Tst()<CR>
> > works as expected, so the problem seems to be with <expr>
> >
> >
> > map <expr> \a Tst()
> > map \b \a<space>
> >
> > function! Tst()
> >       "exe "normal! :   <CR>"
> >
> >       while getchar(1) < 1
> >               sleep 100ms
> >       endwhile
> >
> >       echomsg "Done!"
> > endfunction
>
> To make getchar() work inside the function that's evaluated for an
> <expr> mapping the typeahead needs to be saved, reset and restored
> later.  Thus the function can't get any typeahead.
>
> This can't be changed, because recursive use of the function that gets
> characters is not possible.
>
> I think this is actually what most people want to happen.  If you want
> to pass something tot he function you can give it an argument.
>
> --
> From "know your smileys":
>  ...---...   SOS
>
>  /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
> ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\        download, build and distribute -- http://www.A-A-P.org        ///
>  \\\            help me help AIDS victims -- http://www.ICCF.nl         ///
>

Reply via email to