Re: PATCH: changing terminal cursor form

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Fri, Apr 4, 2025 at 12:27 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Mikael Magnusson wrote:
> > This feels a bit confusing to me, the name suggests it is an array
> > containing enabled extensions, but the above suggests that an empty
> > element can imply an extension is enabled while an entry with a - in
> > front disables it. To me it would make more sense if the value started
>
> The array is intended to be a list of extensions that your terminal
> supports. Each entry typically corresponds to an escape sequence that is
> not covered by termcap. So arguably you are asserting that your terminal
> doesn't support cursor changes when you do:
>   .term.extensions=( -cursor )
> To disable the new zsh feature you might instead use:
>   zle_cursorform=( pending:none overwrite:none insert:none )
>
> The first command is a lie but for disabling a feature it can be simpler
> and won't need adapting if new contexts are added with a default cursor
> shape.
>
> > out with "query" as an element, such that setting .term.extensions=()
> > would disable querying on startup. The documentation also says some
>
> For each extension, there are three possible states: supported,
> unsupported and unknown. Absence from the list communicates the
> "unknown" state and in that case a default applies. For the most part
> terminals simply ignore unrecognised sequences that are nevertheless a
> valid CSI, OSC, etc sequence so it is harmless to enable the use of
> most extensions by default.
>
> If the array started out with all enabled extensions, that'd have to be
> set before the zle module is loaded and users would need to know how to
> filter out individual values. So instead of:
>   .term.extensions+=( -cursor-shape )
> They would need to know how to do:
>   .term.extensions=( ${.term.extensions:#cursor-shape} )

I realized there's another problem with this scheme, the above code is
invalid on older zsh versions producing errors like:
% .term.extensions+=( -cursor-shape )
zsh: unknown file attribute:
which makes it harder to share your config across hosts (wrapping
things in version checks is pretty cumbersome imo).

This problem would be somewhat lessened if we release a version with
namespaces first, and then add mechanisms that use them in the main
shell in a subsequent release.

That aside, I was also wondering if there is a 'context' for programs,
eg is there a mechanism for automatically changing the cursor form
when an external program is running and then when returning to the
shell again? I feel like it would be a bit weird if programs got a
different cursor depending on which vi/emacs/insert/overwrite mode you
were in when you started it, for example, and even if it automatically
switches to a consistent mode before launching programs, it would be
nice to have it as a separate thing maybe?

> You'll be unaffected other than getting an underline cursor for overwrite mode.

I can already say I would hate that, and based on the feedback we got
for the completion suffix being bold by default, I suspect I won't be
the only one :). (here's one example:
13:33 <rudi_s> Hi. I just updated to 4.3.10-test-3 (from 4.1) and I
find the new bold coloring of leading(sic) slashes very distracting. I
found the documentation for suffix but I'm not sure how to set it. How
can I set suffix to none but leave the other values in zle_highlight
at their defaults (with backward compatibility for 4.1 or older
versions)? Thanks.
)

Maybe setting these cursor shapes/colors differently from the default
should instead be left to prompt themes? That way, we can leave the
whole thing disabled by default, and prompt themes can handle any
differing syntax between versions. (This is just a thought, I'm not
sure about it myself).

> Do my attempts at clarification here make sense because I might propagate any lack of clarity to the documentation.

I can't say for sure, but my main confusions were about the
inconsistent statements about what the query-stuff does, so as long as
that's clarified I should be good.

> Should I perhaps apply the patch series despite the outstanding SIGINT issue to at least make it easier for people to test the changes?

There's always the option of pushing it to a new branch too, to make
it easier for gmail users (eg, me) who don't have an easy way to apply
large patches from the list to test it. (I've used the mikachu/
namespace for my one wip patch in the past, which makes it somewhat
clear that it's not considered stable).

-- 
Mikael Magnusson