From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8626 invoked from network); 5 Dec 1996 16:22:31 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 5 Dec 1996 16:22:31 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA11458; Thu, 5 Dec 1996 11:04:23 -0500 (EST) Resent-Date: Thu, 5 Dec 1996 11:04:23 -0500 (EST) From: Zefram Message-Id: <638.199612051604@stone.dcs.warwick.ac.uk> Subject: Re: a plan for ZLE extendability To: pws@ifh.de (Peter Stephenson) Date: Thu, 5 Dec 1996 16:04:48 +0000 (GMT) Cc: zsh-workers@math.gatech.edu In-Reply-To: <199612051421.PAA27640@hydra.ifh.de> from "Peter Stephenson" at Dec 5, 96 03:21:30 pm X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8528.35 X-US-Congress: Moronic fuckers Content-Type: text Resent-Message-ID: <"_jQ5R2.0.zo2.6Alfo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2540 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu >this sounds fine... someone ought to make a few comments... That's what I thought. I'm surprised no one has responded up to now. >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. I considered using the positional parameters -- actually I would have used them for the thingy stack -- but I decided that the hiding of these parameters when another function is called would make it inappropriate. I don't like this aspect of completion functions, partly for this reason. It is also aesthetically displeasing, and illogical, to make changes to the buffer by assigning to the function's arguments. >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 effect of such an option would be equivalent to pushing one of the special thingies, and then the thingies specified. There would in practice still be a need for a special thingy. (There's no overhead in that; there are other things that require thingies to have flags too.) The syntax I am currently leaning towards would have zle -h to push a special thingy, {h}iding the rest of the stack; normal thingies could also be specified, so zle -h get-key would push a special thingy and then push and execute get-key. The result would be the key read as the only visible thingy on the stack; after that had been popped, the special thingy could be popped. Is this close enough to what you had in mind? > I think in any case >bindkey -s can easily be rescued to store an appropriate sequence. Of course, the existing semantics of bindkey -s would be emulated. >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. (1). Each thingy (apart from the special hiding thingy) is just a string, as far as the user is concerned. (Internally the thingy also has a couple of flags.) When a function execution is requested, the top thingy on the stack is popped and looked up as a function name, and that function is then executed. In any case, automatically pushing executed strings back onto the input would be inappropriate. Tty input is not fundamental to this model of ZLE; it's just something handled by the get-key function (with which send-string collaborates). A user could even redefine get-key and send-string, to take input from somewhere else. -zefram