Re: Terminal query artifacts and backward compatibility issue in zsh-dev version

[Oliver Kiddle <opk@xxxxxxx>]

On 7 Dec, Langbart wrote:
> Guten Tag, 

Guten Abend,

> I have noticed an issue with the current dev version of zsh.

If a terminal fails to consume an escape sequence printable parts of the
sequence are printed. Normally, the prompt should wipe it faster than
you can observe it but there are ways to suppress the prompt such as
your example with the sleep. A lot of terminal programs now include
terminal queries as part of their startup including well-known things
like vim and tmux but most have the advantage of clearing the whole
screen to better hide any artifacts.

> To reproduce:
>
> 1. Get macOS and the latest zsh development version
> 2. Open zsh in Apple’s default Terminal.app and run

The "Get macOS" part is not so easy with the hardware I have available
to me. I did test on as many terminals as possible which I thought had
incuded briefly borrowing access to a mac. There were rare instances of
this sort but only on obscure or ancient terminals (from memory, I think
it was CDE's dtterm and the console on DragonflyBSD). And given that
artifacts are quickly wiped by a prompt, I wouldn't consider that to be
a major issue.

Unfortunately, Apple's terminal can't be dismissed for being too obscure
or ancient. It's tempting to make it their problem and gamble that
they'll notice and improve their terminal.

> - A) Can the feature become opt‑in instead of opt‑out?

The main point of the feature is to allow other features to work
correctly without user's explicitly opting in based on feature sets of
their particular terminals. Very few users would opt-in so I find it a
pity to just disable it.

> - B) Can a backward‑compatible way to disable the feature without an
> if‑statement be added, e.g., an environment variable such as: export
> ZSH_TERM_QUERIES='no' ?

My first thought was to suggest that you can avoid this particular query
by setting COLORTERM to either 24bit or truecolor. However, that would
only be any good if Apple's Terminal supported truecolor. There doesn"t
appear to be a standard value for indicating the lack of support and
there may be terminal programs out there that assume truecolor if that
variable is merely set.

These TERMINAL_PROGRAM and TERMINAL_PROGRAM_VERSION environment
variables appear to be macOS specific. We could populate .term.id and
.term.version based on these and avoid the XTVERSION query. To avoid the
problematic RGB query, we'd need to compare TERMINAL_PROGRAM against the
literal "Apple_Terminal" string. I'm reluctant to bloat the code with
lots of heuristics of this sort. Part of the idea of .term.id was to
facilitate writing such things in startup files. But maybe for something
as common as the default macOS terminal? ssh and sudo need to be
configured to pass extra environment variables so this would only be a
partial solution.

There is also a different approach to detecting truecolor support which
some terminal programs take. Basically, they set a colour and then
retrieve the current colour. I'm not especially keen on this: you have
to choose a colour to set, there's a non-zero chance it coincidentally
matches the actual default colour. Type-ahead text or artifacts may end
up using the temporary colour, you need to reset it and what if the
shell is sent signals inbetween.

> .term.extensions=( -query )
>
> BUT this relies on the new namespace syntax, which breaks any script using an
> older zsh (e.g., /bin/zsh on macOS is 5.9).

There's nearly always a way to define things without version tests such
as directly detecting features. I rely on the namespaces being added in
the same release as namerefs. In this case you can redirect errors:

{ .term.extensions+=(-query) } 2>/dev/null

Instead of -query, it would be more useful to explicitly indicate that
the terminal lacks truecolor support by adding -truecolor. If you've
told it whether truecolor is supported, it won't try to detect it. I
also wouldn't put this in .zshenv. zle is normally only loaded for
interactive shells so .zshrc is more applicable.

Oliver