From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5685 invoked by alias); 15 Feb 2014 01:43:04 -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: 32385 Received: (qmail 23683 invoked from network); 15 Feb 2014 01:42:59 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 From: Bart Schaefer Message-id: <140214174253.ZM10203@torch.brasslantern.com> Date: Fri, 14 Feb 2014 17:42:53 -0800 In-reply-to: Comments: In reply to "Jun T." "Re: Commit 137b15a fails X02zlevi test" (Feb 15, 12:59am) References: <140208121311.ZM14905@torch.brasslantern.com> <140208144555.ZM16333@torch.brasslantern.com> <140209105343.ZM24252@torch.brasslantern.com> <17919.1391985011@quattro> <140210233703.ZM11806@torch.brasslantern.com> <140212214922.ZM25943@torch.brasslantern.com> <140213093920.ZM27020@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Commit 137b15a fails X02zlevi test MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 15, 12:59am, Jun T. wrote: } Subject: Re: Commit 137b15a fails X02zlevi test } } On my Fedora 17 and 20, X02zlevi.ztst always succeeds even without } the zpty_flush patch, and on my Mac OS X 10.8/10.9 and FreeBSD 9/10 } it succeeds with the zpty_flush patch (already committed) plus my } previous patch (bind undo to ^K instead of ^R). s/undo/redo/ This is curious. If the collision of the redo binding with the stty reprint character were relevant, it should cause a problem no matter when the key binding occurred. That may mean that the real problem is that ^R is bound to "redisplay" by default ... but then I would still expect ^K to fail as well, since the implication is that the comptesteval isn't working properly. Does it really require BOTH zpty_flush plus and ^K in the FreeBSD case? } 2014/02/14 02:39, Bart Schaefer wrote: } > A "sleep 1" at the top of zpty_flush may take care of this. } } It seems adding 'sleep 1' at the END of zpty_flush works (i.e., } the test succeeds with the zpty_flush patch but undo is bound to ^R). This is also curious. My hypothesis is that the master zsh reads some of the tty control sequences send by the pty-zsh. At least every now and then, the "zpty -t -r ..." in zpty_flush should be that culprit. Putting the sleep at the beginning is meant to prevent that, and then the flush itself should leave a clean slate for whatever comes next. } But this makes the test very slow. Yes, something less than a full 1 second sleep is needed. } Actually, adding a 'sleep 1' after the } } zpty_flush Before zletest } } in zle_test() seems to be enough (at least on my systems and for the } current set of tests), but the test is still rather slow. That seems to imply that it's more important to pause after comptesteval than anywhere else, though it's still odd that it would not be needed *before* the zpty_flush. What happens if you insert "sleep 1" at the end of comptesteval only? Actually for my own system I can *remove* _all_ zpty_flush calls from zle_test and it still works. This makes some sense because the most commonly failing cases are "comptesteval;zle_test" in succession, so there will have been a zpty_flush at the end of comptesteval before zle_test begins. One bit that is clear is that ZLE is outputting "^[[K" (which must be clear-to-eol) after printing the prompt, but both comptesteval and zle_test are only reading up through the prompt itself, leaving those last three characters behind. If subsequent zpty read/write by the master zsh can get mingled with those characters, bad things happen. Other things that appear to be happening are PROMPT_CR and PROMPT_SP (PROMPT_EOL_MARK) output; both of those are options that post-date the writing of Test/comptest.