On Sat, Dec 11, 2010 at 08:57, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 10, 11:40am, Nikolai Weibull wrote:
> }
> } Running zle reset-prompt with a prompt that is COLUMNS wide eats the
> } line above prompt's first line.  Here's a set-up to try it with:
> }
> } PS1=${(l:COLUMNS:)}$'\n'
> } bindkey '^^' reset-prompt
>
> The problem here isn't the width of the prompt, it's the newline.
> (OK, it's sort of the combination of the two, but more the latter.)
>
> } Each time you press CTRL-^ you'll be eating the line above the first
> } line of the prompt.  If you change PS1 to ${(l:COLUMNS-1)}$'\n' this
> } doesn't happen.
> }
> } Would it be possible to have prompt that is COLUMNS wide and have this
> } not happen?
>
> This is a problem with terminals and terminfo or termcap descriptions.
> Some terminals silently discard a newline when one is output at the
> right margin, others don't, and still others discard it only when it
> is output at the right margin of the very last line of the screen.
> Some terminals cause the cursor to wrap onto the next line right
> away when the right margin is reached, others leave the cursor on
> top of the last character that was output until at least one more
> character appears.
>
> Terminal description databases aren't very good at differentiating
> these cases.  ZLE decides in this case that the terminal both wraps
> the line and does not discard the newline, so it believes it needs
> to move up one line before redrawing the prompt.  Your terminal
> wraps at the margin but does discard the newline, so ZLE's internal
> idea of what the screen looks like does not match reality.
>
> You can get around this by replacing $'\n' with $'%1(l.\n.)' which
> means to emit the newline only if ZLE believes that at least one
> character has been output since the last (implicit) newline.  If
> the line is exactly $COLUMNS wide, ZLE will think that the terminal
> has wrapped and that zero characters have been output since, so it
> won't fool itself by emitting a newline that the terminal discards.
>
> On a different terminal, though, you might need to go back to $'\n'
> unconditionally.

It seems that there is some other complication.  I’ve attached my
prompt definition, if anyone wants to take a look.  I’m currently
running through screen inside PuTTY and iTerm, in which this trick
didn’t work.