From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1889 invoked from network); 12 Mar 1999 10:51:25 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 12 Mar 1999 10:51:25 -0000 Received: (qmail 17690 invoked by alias); 12 Mar 1999 10:50:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5774 Received: (qmail 17676 invoked from network); 12 Mar 1999 10:50:33 -0000 Message-Id: <9903121034.AA28601@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: Debug / cut'n'paste on IRIX In-Reply-To: ""Andrej Borsenkow""'s message of "Fri, 12 Mar 1999 13:21:30 NFT." <001201be6c72$18aaa260$21c9ca95@mowp.siemens.ru> Date: Fri, 12 Mar 1999 11:34:31 +0100 From: Peter Stephenson "Andrej Borsenkow" wrote: > Looks, like it is done in settyinfo(), that is (unconditionally) called from > trashzle() that is called from zleread() after we've seen new line. (It is > actually using tcsetattr() on our system) I haven't been into this in enough detail to propose a definite fix, but how about something like: set a flag when calling zleread() from the shell input mechanism (which is where we may need another line) to postpone the trashzle() --- we can make the last argument take or'd flags. Then call trashzle() instead when input processing is really finished: maybe in hend() would do the trick. I can believe it's not that simple. I think you're right that the correct thing to do is something much more sophisticated anyway. But I'm not sure what and I'm not convinced it's ever going to happen. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy