From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8568 invoked from network); 5 Dec 1996 16:03:21 -0000 Received: from euclid.skiles.gatech.edu (root@130.207.146.50) by coral.primenet.com.au with SMTP; 5 Dec 1996 16:03:21 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id JAA09647; Thu, 5 Dec 1996 09:20:47 -0500 (EST) Resent-Date: Thu, 5 Dec 1996 09:20:47 -0500 (EST) Message-Id: <199612051421.PAA27640@hydra.ifh.de> To: zsh-workers@math.gatech.edu (Z Shell workers mailing list) Subject: Re: a plan for ZLE extendability In-reply-to: "Zefram"'s message of "Mon, 02 Dec 1996 12:58:29 MET." <17029.199612021258@bookbind.dcs.warwick.ac.uk> Date: Thu, 05 Dec 1996 15:21:30 +0100 From: Peter Stephenson Resent-Message-ID: <"9g7qw.0.gM2._ejfo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2539 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Zefram wrote: > 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 function. -- Peter Stephenson 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.