Re: Commit 137b15a fails X02zlevi test

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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 <schaefer@xxxxxxxxxxxxxxxx> 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.