Re: PATCH: query terminal properties on ZLE startup

[Oliver Kiddle <opk@xxxxxxx>]

Roman Perepelitsa wrote:
> However, zsh-bench isn't necessary for this particular case. A simple
> benchmark like the following would suffice:
>
>   time ( repeat 1000 zsh -fc 'zmodload zsh/zle' )

Thanks Roman.

It does also need -i. Otherwise, using that as the benchmark, the
difference with and without the terminal querying is not much more
than the fluctations between subsequent runs. Adding a few nested
ssh connections does make a difference.

To see problems, it probably takes network glitches. With greater
use of mobile data connections this probably isn't uncommon.

However, I think most of the problems I saw when querying from my
zsh startup files were instead caused by other things like the
urxvt bug with sequence endings interacting badly with tmux (which
has to pass on and relay background color queries). In the C code,
I've got it accepting the broken responses from urxvt to avoid this.

> In my own zsh startup files, I query the terminal and use a much
> higher timeout of 5s for this. When the timeout triggers, the
> experience is terrible: the shell ends up misconfigured (naturally,
> as the initialization depends on the reply), and zle receives junk
> input unpredictably when the terminal finally responds. I've run
> into this issue a couple of times when connecting over SSH to
> machines with extreme packet loss.

I'll look into whether we can make zsh recognise and drop the junk
input.

Not much we can do about the misconfiguration. My advice would be
to have your setup degrade to something simple and reliable when
it can't determine the colours.

Out of interest, what do you query the terminal for? Anything I
didn't cover in the patch?

> I'd prefer if there were no timeout at all, requiring manual
> interruption with Ctrl-C instead, like other initialization steps and
> hooks. Would that be feasible in your implementation?

Feasible, yes. But while you might prefer that it seems like a poor
experience to give most average users. Anything longer than a 2
second delay leaves a user wondering what's gone wrong.

I did find a couple of terminals that don't respond to any queries,
even the basic device attributes one. These were OS system consoles
so have likely been intentionally kept low on features but that
also means people are occasionally forced into using them. These
need either a timeout or a user pressing Ctrl-C.

While we could make the timeout configurable, I doubt whether there
would really be many users who'd bother and it adds bloat in the
documentation. Applying a scaling factor on $BAUD would be possible
but that doesn't provide a way to disable the timeout and is unlikely
to relect packet loss. And whether or not it's configurable, we
would want to choose a good default.

Oliver