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