On Sun, May 19, 2019 at 7:05 PM Bart Schaefer wrote: > We constantly go around on this. If we un-break it for one terminal > type it breaks for another. It's an acknowledged problem that in some > cases you can't set ZLE_RPROMPT_INDENT=0, that's why the variable > exists in the first place; if it always worked to set it to zero we'd > remove it. > > All your patch does is remove a test for the value of that variable. > A more correct change would be to add to the test condition a check > for whether placing a character in the rightmost column (or the > rightmost/bottom-most position) causes the terminal to auto-wrap (or > not) the cursor onto the next line. At first I thought that on my terminal (GNOME Terminal) there is auto-wrapping when RPROMPT is written at the very right edge. It can be seen when I set RPROMPT='%K{red}X' and ZLE_RPROMPT_INDENT=0, which results in an extra line below the prompt with a red cell on the left. Then, after some debugging, I realized that it's not my terminal that causes auto-wrapping but ZSH. zputs(rpromptbuf, shout) at zle_refresh.c:1680 doesn't create that new line even when ZLE_RPROMPT_INDENT=0. The following ZSH code does. That's why my patch doesn't just disable a condition but also adjusts vcs after zputs(rpromptbuf, shout). Do I understand you correctly that prior to my patch ZSH handled ZLE_RPROMPT_INDENT=0 correctly on terminals that do auto-wrap after RPROMPT is written, but my patch broke them? If so, could point me to such a terminal? It would be very helpful. I realize that you've had this discussion a million times and I appreciate your patience. What $ZSH_PATCHLEVEL were you testing against? There was a related > change committed only a month ago, and there has not been a release in > the meantime. > echo $ZSH_PATCHLEVEL zsh-5.7.1-77-gfae7c85 My fork is currently 1 commit ahead of zsh-users/zsh on github. Roman.