Zsh Mailing List Archive
Messages sorted by:
Re: a plan for ZLE extendability
- X-seq: zsh-workers 2539
- From: Peter Stephenson <pws@xxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx (Z Shell workers mailing list)
- Subject: Re: a plan for ZLE extendability
- Date: Thu, 05 Dec 1996 15:21:30 +0100
- In-reply-to: "Zefram"'s message of "Mon, 02 Dec 1996 12:58:29 MET." <17029.199612021258@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> There is a need for ZLE to be extendable without having to write a
> binary module.
> To this end, I have devised the following system.
this sounds fine... someone ought to make a few comments...
> The third requirement (modification of buffers) can be met most generally
> by adding a special parameter -- perhaps $ZLE_BUFFER -- that can be
> assigned to. $ZLE_MINIBUFFER would also be required. To control
> the cursor position, $ZLE_BUFFER could be split into two parameters,
> representing the parts of the buffer before and after the cursor.
You can avoid $ZLE_BUFFER by doing like what completion does and
passing the buffer as arguments $1 and $2 of the function. I think
the drawback is you need some kind of arrangement with the function
call mechanism to get the returned values of $1 and $2; maybe nested
functions are less intuitive and less efficient this way, too.
> There is a need to be able to perform actual input even
> when the stack is non-empty. Probably the neatest way to do this is to
> have a special thingy that (when at the top of the stack) will cause
> the input functions to perform input anyway.
What's the objection to e.g. having a special option to zle that
causes the arguments to be executed immediately? Or one that causes
just the top N thingies on the stack to be executed (or the possibility
of both)? That would avoid having special thingies.
> The "send string" functionality can be handled in one of two ways.
> The first possibility is to treat it as it is now, as a special case
> in getkeycmd(). The second possibility, that I generally prefer, is to
> make it into a normal ZLE function, taking an argument, and allow keys
> to be mapped to any sequence of thingies.
One thing that's missing at the moment is being able to bind to
sequences of functions, instead of just a rather opaque string of
characters which may or may not be bound to the desired functions, so
the second alternative is definitely desirable. I think in any case
bindkey -s can easily be rescued to store an appropriate sequence.
I didn't quite get whether thingies are typed: are (1) thingies
interpreted as functions when first popped and only as strings when
required as an argument, or (2) either pushed on the stack as
functions or as strings? If (2) then a string encountered as a
function can simply be sent without needing any specific send-string
Peter Stephenson <pws@xxxxxx> Tel: +49 33762 77366
WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.
Messages sorted by: