Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Confirming X02zlevi test failures
- X-seq: zsh-workers 33719
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: Confirming X02zlevi test failures
- Date: Wed, 19 Nov 2014 22:20:19 -0800
- In-reply-to: <11014.1416438322@quattro>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <141119085006.ZM18951@torch.brasslantern.com> <11014.1416438322@quattro>
On Nov 20, 12:05am, Oliver Kiddle wrote:
}
} While it is not the feature that test is there to test, it'd really be
} better to understand why KEYTIMEOUT isn't working in the test cases.
I instrumented raw_getbyte() and calc_timeout(). Found a couple of
things.
One, there's still a race condition with the PTY. In random cases,
the cursor motion output that's sent by ZLE can be seen by the slave
PTY as if it were input from the master PTY:
0 0 88 <- first time into calc_timeout(), no timeout, 88 is garbage
^[ <- saw the escape character
1 1 1 <- we should time out in 1/100th second
^H <- OOPS! Read the backspace (output) as input?!
~ <- And there's the tilde
The second thing I found is that, possibly for the same reason, the
delayzetterm flag is (inconsistently in terms of zletest input, but
consistently for this particular test) getting set, which causes
KEYTIMEOUT to be ignored. The comment for delayzetterm says:
* Problems can occur on some systems when switching from
* canonical to non-canonical input. The former is usually
* set while running programmes, but the latter is necessary
* for zle. If there is input in canonical mode, then we
* need to read it without setting up the terminal. Furthermore,
* while that input gets processed there may be more input
* being typed (i.e. further typeahead). This means that
* we can't set up the terminal for zle *at all* until
* we are sure there is no more typeahead to come. So
* if there is typeahead, we set the flag delayzsetterm.
* Then getbyte() performs another FIONREAD call; if that is
* 0, we have finally used up all the typeahead, and it is
* safe to alter the terminal, which we do at that point.
So ... for some reason zsetterm() believes that there is typeahead and
delays switching out of the canonical mode for too long. This seems
to happen only when ESC is the first character written to the PTY, but
I'm not 100% sure of that.
Unfortunately, I don't know what to do about this, yet. Thoughts?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author