From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7716 invoked from network); 28 Sep 1999 09:29:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Sep 1999 09:29:48 -0000 Received: (qmail 28843 invoked by alias); 28 Sep 1999 09:29:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8081 Received: (qmail 28836 invoked from network); 28 Sep 1999 09:29:35 -0000 Message-Id: <9909280854.AA28230@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: Weird behaviour with certain PS1-sequences In-Reply-To: "Dan Nelson"'s message of "Mon, 27 Sep 1999 17:06:47 DFT." <19990927170647.A5674@dan.emsphone.com> Date: Tue, 28 Sep 1999 10:54:04 +0200 From: Peter Stephenson Dan Nelson wrote: > % zsh -f > % PROMPT="%m %n %/ %%" > dan dan /home/dan % TERM=dumb > dan dan /home/dan % > ^ blanks start here and don't stop Yes, I can see this, and what's going wrong, in the refresh code. Unfortunately I'm not sure I understand the logic well enough to fix it, though if Geoff doesn't get around to it I will have to try. The spaces in the prompt match what is on the line already at that point, i.e. nothing. singmoveto() is called to skip over them, one by one. (Since we're skipping only one character in this example, it would presumably be more efficient just to output it, but that's a different question.) singmoveto() correctly finds out that we need to move one character to the right, and calls tc_rightcurs() to do this. Here, all the easy things you can do with proper terminals fail, and it gets down to the code currently around line 948 for dumb terminals. This is where all hell breaks loose. For reasons I am totally at a loss to understand, if we are printing in the prompt, as we currently are, the code assumes we can just write out the entire rest of the prompt, then fix the position up after. But, obviously, in this case fixing up after means skipping back over all the unnecessary characters we've just printed to get where we were. The code correctly counts the offset we need to fix up the position, but it's minus something because we're way past. The remainder of tc_rightcurs() assumes this offset (ct) is positive and tries to output spaces to match, which puts it into a loop eternally decrementing ct, at least until it wraps round after 4,000,000,000 or so. The obvious simple fix is to write out only the bit of the prompt we need to advance to the right position. But I don't understand why it's the way it is at the moment, so I'd better not try to rewrite it myself. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy