From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3172 invoked from network); 2 Nov 2000 17:31:02 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Nov 2000 17:31:02 -0000 Received: (qmail 10625 invoked by alias); 2 Nov 2000 17:30:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13110 Received: (qmail 10618 invoked from network); 2 Nov 2000 17:30:53 -0000 From: "Bart Schaefer" Message-Id: <1001102173042.ZM19733@candle.brasslantern.com> Date: Thu, 2 Nov 2000 17:30:42 +0000 In-Reply-To: <0G3E0018CA6WEG@la-la.cambridgesiliconradio.com> Comments: In reply to Peter Stephenson "PATCH: Polite output from traps with zle active" (Nov 2, 11:20am) References: <0G3E0018CA6WEG@la-la.cambridgesiliconradio.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: PATCH: Polite output from traps with zle active MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 2, 11:20am, Peter Stephenson wrote: } Subject: PATCH: Polite output from traps with zle active } } TRAPUSR1() { } zle -I } print Hello, I am output } zle -R } } } } It's possible there are extra safeguards I should have added but missed. } If anyone thinks this should be done a different way, now would be a good } time to mention it. It's too bad that the trap writer has to call `zle -R' as well as `zle -I'. What happens if you accidentally call only `zle -I'? I can see how the zsh trap handler can't possibly know in advance whether the user-defined trap will produce output, and therefore shouldn't do a trashzle() on its own -- but surely it could detect whether zle has been trashed and do the zrefresh() automatically? If there really is some valid use for trashing zle without refreshing it, perhaps another parameter to `zle -I' (or even something like `zle +I') could be used to suppress the eventual zrefresh(). } It alters zle -R to allow it to be called when zle is not active --- } it simply returns zero --- and adds `zle -I' (invalidate), which } simply calls trashzle(). Both are allowed when zle is not active (and } do nothing) because there is no good reason for forcing the onus of } deciding whether the display needs to be cleared and refreshed onto } the writer of the trap function. It'd also be nice if `zle -R' and `zle -I' returned zero when zle is active and nonzero otherwise, just as `zle' with no arguments does. There may not be much use for this, since probably one most often wants to test for zle *before* invalidating it, but there is some benefit to consistency. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net