From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16610 invoked by alias); 25 Sep 2011 21:44:43 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29799 Received: (qmail 26943 invoked from network); 25 Sep 2011 21:44:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110925144416.ZM19577@torch.brasslantern.com> Date: Sun, 25 Sep 2011 14:44:16 -0700 In-reply-to: Comments: In reply to Mikael Magnusson "Re: prompts with newlines get printed twice" (Sep 24, 8:31pm) References: <110924112412.ZM24918@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: prompts with newlines get printed twice MIME-version: 1.0 Content-type: text/plain; charset=us-ascii [>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.