From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17293 invoked from network); 11 Mar 2000 08:00:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Mar 2000 08:00:53 -0000 Received: (qmail 17819 invoked by alias); 11 Mar 2000 08:00:45 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10070 Received: (qmail 17782 invoked from network); 11 Mar 2000 08:00:43 -0000 From: "Bart Schaefer" Message-Id: <1000311075721.ZM19210@candle.brasslantern.com> Date: Sat, 11 Mar 2000 07:57:21 +0000 In-Reply-To: <200003091221.NAA25853@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: The `zle' command and traps" (Mar 9, 1:21pm) References: <200003091221.NAA25853@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: The `zle' command and traps MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 9, 1:21pm, Sven Wischnowsky wrote: } Subject: Re: The `zle' command and traps } } Bart Schaefer wrote: } } > TMOUT=2 ; TRAPALRM() { zle -R "Hi there, I'm a trap." } } > } > Of course if the signal arrives when ZLE is not active, this generates an } > ugly warning message. } } I was about to add a/some test(s) for sfcontext in bin_zle() } but... this is quite cool, isn't it? ;-) Yes, I confess I thought so too ... but some things don't work so well. For example, try using "zle -M ..." instead of -R in that trap. Or try TRAPINT() { zle push-input } and then type ctrl-C. Note that the line gets pushed onto the buffer stack, but the display is not refreshed so you can't tell. You need an explicit refresh: TRAPINT() { zle push-input ; zle -R } (An explicit refresh makes the "zle -M" trap work as well.) I'm also concerned about what happens if a zle widget is invoked from a trap in the middle of some interactive thing like menu-selection. That could get messy quickly, especially if it's something that alters the buffer. } So, should we disallow it completely? I can't decide. The message modes and refresh seem harmless enough, but perhaps we should refuse to execute widgets from within traps? } Or make the zle builtin be quiet if zle isn't active? That isn't strictly necessary as one can redirect stdout to hide the warning. However, it'd be nice if zle returned a non-zero status when it fails; try typing zle -R "not echoed" || echo zle failed and you'll get zle: can only be called from widget function but not "zle failed". } Make the zle special parameters accessible (read-only) in traps if zle } is active? If we allow widgets to be called, you can cause the special parameters to become available by using "zle widgetname". So instead of writing TRAPINT() { .... something with $BUFFER .... } One writes widgetname() { .... something with $BUFFER .... } zle -N widgetname TRAPINT() { zle widgetname } Can you extend read-only-ness of the parameters to the point that widgets are restricted as well? I.e., if you call from a trap a builtin widget that moves the cursor or inserts/deletes characters, it would fail? If we can restrict widgets to those that do "safe" things, then we can allow "zle widgetname" and there's no need for the special parameters to be visible directly to the trap function. If instead we must prohibit widget-calling entirely, then perhaps the parameters should be available to the trap function. } Add a way to detect if zle is active? That would be nice. "zle" with no arguments silently returning 0 or 1 would be sufficient (it now says "zle: widgets can only be called ..."). While we're on the subject ... CURSOR is almost equivalent to emacs' (point). Why is there no MARK variable? I find myself wanting to play with the region and therefore doing things like local -i point=$CURSOR zle exchange-point-and-mark local -i mark=$CURSOR zle exchange-point-and-mark } Add a way to detect if (the shell thinks that) there is a } completion list displayed below the prompt? Etc, etc? Hrm. That may be getting too esoteric. Hard to say. While we're on the subject of zle behavior: zle -U frob This results in "brof" being inserted onto the command line. The docs refer to the "input queue" not the "input stack" -- why is it LIFO? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com