Re: zle reset-prompt with prompt that is COLUMNS wide eats line above prompt's first line

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.