From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9513 invoked from network); 18 Jul 2005 18:13:46 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Jul 2005 18:13:45 -0000 Received: (qmail 68973 invoked from network); 18 Jul 2005 18:13:40 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Jul 2005 18:13:40 -0000 Received: (qmail 10178 invoked by alias); 18 Jul 2005 18:13:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21492 Received: (qmail 10165 invoked from network); 18 Jul 2005 18:13:36 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Jul 2005 18:13:36 -0000 Received: (qmail 68656 invoked from network); 18 Jul 2005 18:13:36 -0000 Received: from dsl3-63-249-88-2.cruzio.com (HELO dot.blorf.net) (63.249.88.2) by a.mx.sunsite.dk with SMTP; 18 Jul 2005 18:13:32 -0000 Received: by dot.blorf.net (Postfix, from userid 1000) id 9614E4CB; Mon, 18 Jul 2005 11:13:30 -0700 (PDT) Date: Mon, 18 Jul 2005 11:13:30 -0700 From: Wayne Davison To: Peter Stephenson Cc: Zsh hackers list Subject: Re: PATCH: PROMPT_SP Message-ID: <20050718181330.GA19066@blorf.net> References: <20050714182506.GB11296@blorf.net> <20050715175551.GA29713@blorf.net> <1050716160634.ZM31049@candle.brasslantern.com> <20050716195612.GA11575@blorf.net> <200507181032.j6IAWB4q022520@news01.csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507181032.j6IAWB4q022520@news01.csr.com> User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=ham version=3.0.4 On Mon, Jul 18, 2005 at 11:32:11AM +0100, Peter Stephenson wrote: > Here's an update to the FAQ entry. Good idea. I think it might be better to do a bigger rewrite, though, so that we indicate early on that this FAQ entry's problem is largely solved by PROMPT_SP. What do you think of the following? (Hopefully my improved precmd function is not too complex.) --- Etc/FAQ.yo 18 Jul 2005 14:54:11 -0000 1.20 +++ Etc/FAQ.yo 18 Jul 2005 18:03:36 -0000 @@ -1640,43 +1640,49 @@ sect(How do I prevent the prompt overwriting output when there is no newline?) - The problem is, for example, + The problem is normally limited to zsh versions prior to 4.3.0 due to the + advent of the PROMPT_SP option (which is enabled by default, and eliminates + this problem for most terminals). An example of the overwriting is: verb( % echo -n foo % ) - and the tt(foo) has been overwritten by the prompt tt(%). The reason this - happens is that the option tt(PROMPT_CR) is enabled by default, and it - outputs a carriage return before the prompt in order to ensure that the - line editor knows what column it is in (this is needed to position the - right-side prompt correctly (mytt($RPROMPT), mytt($RPS1)) and to avoid screen - corruption when performing line editing). If you add tt(unsetopt promptcr) - to your tt(.zshrc), you will see any partial output, but your screen may - look weird until you press return or refresh the screen. - - Another solution for many terminals is to define a precmd function that - outputs a screen-width of spaces, like this: - verb( - function precmd { - echo -n ${(l:$COLUMNS:::):-} - } - ) - (Explanation: an empty parameter expansion is padded out to the number of - columns on the screen.) That precmd function will only bump the screen - down to a new line if there was output on the prompt line, otherwise the - extra spaces get removed by the tt(PROMPT_CR) action. Although this - typically looks fine it may result in the preceding spaces being included - when you select a line of text with the mouse. + This shows a case where the word tt(foo) was output without a newline, and + then overwritten by the prompt line tt(%). The reason this happens is that + the option tt(PROMPT_CR) is enabled by default, and it outputs a carriage + return before the prompt in order to ensure that the line editor knows what + column it is in (this is needed to position the right-side prompt correctly + (mytt($RPROMPT), mytt($RPS1)) and to avoid screen corruption when performing + line editing). If you add tt(unsetopt promptcr) to your tt(.zshrc), you + will see any partial output, but your screen may look weird until you press + return or refresh the screen. + + A better solution than disabling PROMPT_CR (for most terminals) is adding + a simpler version of the PROMPT_SP functionality to an older zsh using a + custom precmd function, like this one: + verb( + # Skip defining precmd if the PROMPT_SP option is available. + if ! eval '[[ -o promptsp ]] 2>/dev/null'; then + function precmd { + # An efficient version using termcap multi-right: + echo -n ' ' # Output 1 space + echotc RI $((COLUMNS - 3)) + echo -n ' ' # Output 2 spaces + # Alternately, try replacing the above 3 lines with this echo + # that outputs a screen-column-width of spaces: + #echo -n ${(l:$COLUMNS:::):-} + } + fi + ) + That precmd function will only bump the screen down to a new line if there + was output on the prompt line, otherwise the extra spaces get removed by + the tt(PROMPT_CR) action. Although this typically looks fine it may result + in the preceding spaces being included when you select a line of text with + the mouse. One final alternative is to put a newline in your prompt -- see question link(3.13)(313) for that. - Version 3.0 of zsh includes a workaround: if the tt(PROMPT_SP) option - is set, as it is by default, the shell will try to move the cursor to the - start of the next screen line. This requires some support from the - terminal which is available in most recent terminal emulators. - - sect(What's wrong with cut and paste on my xterm?) On the majority of modern UNIX systems, cutting text from one window and ..wayne..