Re: Commit 137b15a fails X02zlevi test

["Jun T." <takimoto-j@kba.biglobe.ne.jp>]

2014/02/15 10:42, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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.

I'm not sure whether I have understood your point correctly, but
I guess 'bindkey -a "^R" redo' itself isn't causing a trouble.
The problem is the '^R' sent by zletest $'123\C-_\e\C-r'.
The slave-side zsh should set its tty input into non-canonical mode
when Zle is active, but I suspect that it fails (or delays) to do so
and the ^R does has a effect of reprint.

>  Does it really require BOTH
> zpty_flush plus and ^K in the FreeBSD case?

Yes, both on Mac and FreeBSD.
Without the zpty_flush patch, all the tests which use comptesteval
fail (unless the test is the 1st test in X02zlevi.ztst).
With the zpty_flush patch, only the test with 'bindkey -a "^R" redo'
fails. This test succeeds if ^R is replaced by ^K.

> What happens if you insert "sleep 1" at the end of comptesteval only?

Works on FreeBSD but not on Mac (about 50% failure). I don't know why.

But adding 'sleep 1' at the beginning of zletest() seems to work on
both Mac and FreeBSD (adding it after the 'zpty_flush Before zletest'
is also OK).

# Adding 'sleep 1' is to make the last failing test (^R-redo test) to
# succeed (with zpty_flush patch applied but redo is bound to ^R).

> Actually for my own system I can *remove* _all_ zpty_flush calls from
> zle_test and it still works.

Maybe the only call of zpty_flush necessary is
'zpty_flush After comptesteval'
in comptesteval(); all the other zpty_flush call can be removed.
With this single call of zpty_flush and ^R --> ^K, all the test pass
on Mac and FreeBSD (without adding sleep anywhere).