promptcr workaround

promptcr workaround

[Karl Chen]

I've always been unsatisfied with the answer to FAQ entry
3.23 "How do I prevent the prompt overwriting output when there is
no newline?"  I dislike zsh's promptcr behavior both on and off.
I don't like silently losing the last line nor having a messed-up
prompt, and didn't like adding an extra newline on every command.

Here's a way to simulate adding the \n only when necessary:

    function precmd {
        echo -n ${(l:$COLUMNS:::)}
    }

This prints $COLUMNS spaces.  Iff there's any output on the line
already, it'll wrap to somewhere on the next line.  So when zsh
prints the \r it'll always erase only spaces.


-- 
Karl 2005-03-01 00:10

Re: promptcr workaround

[Wayne Davison]

On Tue, Mar 01, 2005 at 12:17:43AM -0800, Karl Chen wrote:
> Here's a way to simulate adding the \n only when necessary:
> 
>     function precmd {
>         echo -n ${(l:$COLUMNS:::)}
>     }

Nice!  I have the no_unset option turned on, so your suggestion outputs
a warning for every precmd, so I changed the echo to this:

    echo -n ${(l:$COLUMNS:::):-}

Thanks for the nice heuristic!

..wayne..

Re: promptcr workaround

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

What do folks think of including this idea in the FAQ?  I've attached a
patch that does this.

..wayne..

[-- Attachment #2: faq.patch --]
[-- Type: text/plain, Size: 1930 bytes --]

--- Etc/FAQ.yo	17 Jan 2005 10:49:51 -0000	1.15
+++ Etc/FAQ.yo	1 Mar 2005 17:03:56 -0000
@@ -1667,15 +1667,25 @@ sect(How do I prevent the prompt overwri
     % echo -n foo
     % 
   )
-  and the tt(foo) has been overwritten by the prompt tt(%).  The answer is
-  simple:  put tt(unsetopt promptcr) in your tt(.zshrc).  The option \
-  tt(PROMPT_CR),
-  to print a carriage return before a new prompt, is set by default because
-  a prompt at the right hand side (mytt($RPROMPT), mytt($RPS1)) will not appear
-  in the right place, and multi-line editing will be confused about the line
-  position, unless the line starts in the left hand column.  Apart from
-  tt(PROMPT_CR), you can force this to happen by putting a newline in the
-  prompt (see question link(3.13)(313) for that).
+  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.  A better
+  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:::):-}
+    }
+  )
+  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.  One final alternative is to put a
+  newline in your prompt -- see question link(3.13)(313) for that.
 
 
 sect(What's wrong with cut and paste on my xterm?)

Re: promptcr workaround

[Bart Schaefer]

On Mar 1, 12:17am, Karl Chen wrote:
}
} Here's a way to simulate adding the \n only when necessary:
} 
}     function precmd {
}         echo -n ${(l:$COLUMNS:::)}
}     }
} 
} This prints $COLUMNS spaces.

The only trouble with this is that it's really annoying when doing
cut-and-paste, because triple-click to select the whole line will
select all those trailing spaces as well.

See also  http://www.zsh.org/mla/workers/2004/msg01117.html  or
http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=20472
(the latter gets an internal server error as of this writing, but
is otherwise theoretically more stable than the former).

Re: promptcr workaround

[Danek Duvall]

On Tue, Mar 01, 2005 at 05:39:51PM +0000, Bart Schaefer wrote:

> The only trouble with this is that it's really annoying when doing
> cut-and-paste, because triple-click to select the whole line will
> select all those trailing spaces as well.

repeat $COLUMNS echoti cuf1 ?

Danek

Re: promptcr workaround

[Wayne Davison]

On Tue, Mar 01, 2005 at 10:20:18AM -0800, Danek Duvall wrote:
> repeat $COLUMNS echoti cuf1 ?

That won't wrap on most terminals, so you'd have to do something like
this:

    repeat $(( $COLUMNS - 2 )) echoti cuf1
    echo -n '  '

However, that puts one or two spaces into the end of the line, so it
may not change the copy behavior that Bart was complaining about (my
terminal program doesn't behave the way Bart's does, so I don't know
if that's any better or not -- probably not).

..wayne..

Re: promptcr workaround

[Karl Chen]

>>>>> On 2005-03-01 08:41 PST, Wayne Davison writes:

    Wayne> I have the no_unset option turned on

Forgot about that!

    Wayne>     echo -n ${(l:$COLUMNS:::):-}

That's better; I've changed mine also.

    Wayne> Thanks for the nice heuristic!

Glad someone else found that useful.  After writing "command;echo"
for a while it was a nice moment when that came to me :)

-- 
Karl 2005-03-01 11:48

Re: promptcr workaround

[Clint Adams]

> See also  http://www.zsh.org/mla/workers/2004/msg01117.html  or
> http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=20472
> (the latter gets an internal server error as of this writing, but
> is otherwise theoretically more stable than the former).

By the way, problems I have with this method are that it slows things
down, and eats input before the prompt is displayed.