From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2513 invoked from network); 27 Oct 2003 16:57:46 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 27 Oct 2003 16:57:46 -0000 Received: (qmail 3765 invoked by alias); 27 Oct 2003 16:57:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19204 Received: (qmail 12117 invoked from network); 27 Oct 2003 16:42:38 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 27 Oct 2003 16:42:38 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [4.3.58.249] by sunsite.dk (MessageWall 1.0.8) with SMTP; 27 Oct 2003 16:42:38 -0000 Received: (from schaefer@localhost) by candle.brasslantern.com (8.11.6/8.11.6) id h9RGgaW17660 for zsh-workers@sunsite.dk; Mon, 27 Oct 2003 08:42:36 -0800 X-Authentication-Warning: candle.brasslantern.com: schaefer set sender to barton.schaefer@verizon.net using -f From: Bart Schaefer Message-Id: <1031027164236.ZM17659@candle.brasslantern.com> Date: Mon, 27 Oct 2003 16:42:36 +0000 In-Reply-To: <5005.1067258204@csr.com> Comments: In reply to Peter Stephenson "Re: Improved url-quote-magic" (Oct 27, 12:36pm) References: <5005.1067258204@csr.com> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Cascading widgets (Re: Improved url-quote-magic) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii [redirected from -users to -workers] On Oct 27, 12:36pm, Peter Stephenson wrote: } } Bart Schaefer wrote: } > To repeat my comment from 5424: Hey, zsh-workers, there's no good way } > to "stack" functions like this one so that, e.g., you could use it at } > the same time as insert-and-predict. } } I don't quite know what that means, but it seems to be something like } having a stream of data from the keyboard which gets modified and then } passed up to some other handler as if it came raw. No, that's not what I had in mind. For one thing, the data from the keyboard is less interesting than the state of the buffer after the widget has executed. In the case of predict-on/predict-off, executing predict-on redefines self-insert and executing predict-off sets it back to ".self-insert". If self-insert had previously been redefined as url-quote-magic, that binding is lost. Widget push/pop can be fudged with "zle -A" as you did in minibuffer-{push,pop}-widget, but only at the risk of name collisions. Maybe that's minimal enough that we shouldn't worry. More generally, though, I might prefer to have url-quote-magic quote the input key and then still have insert-and-predict attempt to find a matching line. For this to work right now, predict-on would have to remember the previous self-insert binding, and insert-and-predict would have to call that widget rather than modifying LBUFFER directly. That breaks down as soon as there are two such widgets; they'll end up infinitely calling back to one another. I guess I'm just looking for a way to generalize such cascades, so that widget writers don't have to think explicitly about it. Maybe something similar to "compset" but that could be called to change the ZLE state, which would keep track of the "stack position" and do the calls to the previous incarnations of various widgets. I admit I haven't thought this through very far yet; it would need options to specify insertions, deletion ranges, modification ranges, etc.