Re: prompts with newlines get printed twice

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

[>workers]

On Sep 24,  8:31pm, Mikael Magnusson wrote:
}
} I'm seeing some strange behaviour here, when I resize after setting
} PS1='%D{%s} hello
} there '
} I do get the first line twice, but subsequent resizes properly redraws
} both lines in place, updating the time too. Pressing enter then causes
} the next resize to double the first line and then subsequent ones work
} again.

Hmm.

I've traced this to adjustwinsize() called from zhandler().  It makes
these two calls:

1694            zleentry(ZLE_CMD_REFRESH);
1695            zleentry(ZLE_CMD_RESET_PROMPT);

The first one calls zrefresh() which erases the current line and then
prints the prompt (lines 1126 - 1129 of zle_refresh.c) and calls
fflush(shout).  The second then goes through redisplay(), which moves
up one line to the beginning of the just-printed prompt and sets
resetneeded, but the prompt is never printed nor is shout flushed.

On subsequent calls to the handler, when the prompt is printed the
up-line from the previous call is finally flushed BEFORE the prompt
is printed by zrefresh(), so the prompt is accidentally displayed in
the right place.  But I can't believe that it's useful to leave that
up-line lingering in the shout buffer.  I'm still not sure why that
doesn't cause a problem when resizing is done and editing resumes;
it must be because resetneeded is also left hanging.

Can anyone think of a reason not to swap the order of those calls in
adjustwinsize()?  That seems to completely resolve the problem with
vertical resizing.  There's still an issue with horizontal resize
where, if the number of lines in the prompt increases due to the
window becoming too narrow, redisplay() uses the new prompt size and
moves up too far, which may cover up some of the previous command's
output.  Fixing that would seem to be a more significant change, to
keep the old lines/columns around until after lprompth is computed
or some such.