On 4/22/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Yakov Lerner wrote:
>
> > On 4/21/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > > Yakov Lerner wrote:
> > > > On 4/21/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > > > > Yakov Lerner wrote:
> > > > > > At the request of Nikolai Weibull, I made a patch, the
> > > > > > pushkeys({string}) function which add keys sequence to the
> > > > > > typeahead bufer.
> > > > > This breaks a few things:
> > > > > - server_to_input_buf() is only present when FEAT_CLIENTSERVER is
> > > > > defined=
> > > > .
> > > > > - it changes the text "<cr>" to a CR character
> > > > > - it deletes characters from a previous mapping
> > > > >
> > > > > Should use ins_typebuf() directly.
> > > > >
> > > > > Docs could be better...
> > > >
> > > > I fixed these issues
> > > > - Docs expanded.
> > > > - We use ins_typebuf() directly now.
> > > > - Specals keys are now recognized as "\<cr>" not "<cr>".
> > > > - It's not dependent on FEAT_CLIENTSERVER now.
> > > >
> > > > Added remap/noremap flag argument.
> > >
> > > The second argument is optional, you should check if it's there.
> > >
> > > I don't want to change input_available() this way, I can't oversee what
> > > the implications are.
> > >
> > > Also, it's not clear what was already in the input buffer, that makes
> > > the effect rather unpredictable.
> > >
> > > This will have to wait until later.
> >
> > Ok, let me know when you want to get back to this.
> >
> > For the record, I don't understand why variable 'received_from_client'
> > is needed. And why (typebuf.tb_len!=0) can't be used in its place
> > as simpler equivalent. I think it's simpler.
>
> This is the reason I don't want to include it now.Here is another try, less instrusive. We make 'received_from_client' serve both cases, the clientserver and the pushkeys() case, only with appropriate change in ifdefs. Logic of input_available() is not intruded upon now, except for ifdefs. Yakov
pushkey.patch3
Description: Binary data
