Re: PATCH: changing terminal cursor form

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Thu, Apr 3, 2025 at 10:11 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Mikael Magnusson wrote:
> > Will this leave my cursor color/shape alone if I don't do anything to
> > enable this mechanism? (I already have things set up in shell code
> > which do things this system doesn't appear to be able to do).
>
> A default shape is set for three contexts and if you use those contexts,
> it will change the cursor. More generally, if you use emacs mode you
> probably won't notice anything whereas vi mode is noticeably affected.
> The exception to that generalisation is overwrite-mode for which this
> does currently set a default. We could drop that or overwrite and
> (vi)replace could be separate contexts. However there's also a strong
> case for setting a default for regionstart and regionend because the
> default behaviour with a reverse video region and reverse block cursor
> is not ideal.
>
> A web search brings up many cases of vi mode users either seeking help
> or sharing .zshrc files, primarily to toggle between a bar and block
> cursor for insert/normal mode. I'm not even finding other use cases. I'd
> rather that we provide a better default experience for a good few users
> where the cost is inconveniencing a small number of fairly advanced
> users such as yourself into adding .term.extensions+=( -cursor ) to
> .zshrc.

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
out with "query" as an element, such that setting .term.extensions=()
would disable querying on startup. The documentation also says some
things that seem a bit conflicting, the entry for .extensions claims

  When ZLE starts, it will add entries for
  features that were auto-detected.  This auto-detection uses extensions itself,
  all named with a `tt(query)' prefix.

but the entries for the query-foo values only state that they query
the foo value, not that foo feature is "detected" and enabled in any
way, for example,

+item(tt(query-cursor) <E>)(
+Query the cursor color. This facilitates restoring the cursor to its original
+color if it has been configured via tt(zle_cursorform). The color is also
+assigned to tt(.term.cursor).

Perhaps a user would like to query the cursor color and have access to
its values, without enabling the other automagic cursor color/shape
changes? And analogously for the other stuff.

I also don't understand (from the documentation) if setting -cursor
will disable the querying, or if it would still query but then not
enable the cursor extension (or some other result)? Would setting
-query-cursor have a different result? (assuming it is done before ZLE
init)

Actually after rereading the documentation I am even more confused,
there is "query-cursor", but no "cursor", only "cursor-color" and
"cursor-shape", but query-cursor only queries the color, and enables
both of these features? Meanwhile the color is stored in .term.cursor,
not .term.cursorcolor, and is customized via zle_cursorform. Maybe
some consistency with the naming would be helpful here.

> I'd be interested in more details of what you do which this system
> doesn't handle.

There's a few more bits than this (precmd/exec callsites etc), but I
think this shows the general idea,

function cursorcol() {
  printf '\e]12;%s\a' $1
}

function cursorcol_normal() {
  case ${ZLE_STATE:-} in
    *overwrite*)
      cursorcol green
      ;;
    *)
      [[ $UID = 0 ]] && cursorcol red || cursorcol \#A6CAF4
      ;;
  esac
}

function _generic_cursorcol() {
  #zle -R completing...
  cursorcol cyan
  { _generic "$@" } always {
    cursorcol_normal
  }
}
() for 1 {
  zle -C $1 $1 _generic_cursorcol
} complete-word reverse-menu-complete complete-word menu-complete
menu-expand-or-complete

I suppose that your new system won't really interfere with this too
much, but historically we have opted to not enable new features by
default when they can conflict with existing configurations. I'm not
vetoing it or anything, but we could also consider just adding it to
the newuser wizard thingy?

> I'm aware that this has added something analagous to
> zle_highlight without an equivalent to region_highlight. To extend this
> out for custom widgets, something like a CURSORCONTEXT zle widget
> variable to which you could assign a custom context to would be one
> option. It'd be up to the widget writer to ensure it gets unset later.
> That approach doesn't handle competing widgets that both want to use the
> variable. Maybe CURSORCONTEXT could be an array (for a stack) or perhaps
> that's over-complicating things. Would that handle your use case?
>
> Also, should the naming be .zle.cursorform? I didn't use the namespace
> because it is similar to zle_highlight. Maybe we should make the old
> names namerefs into the namespace?

I've never seen the word cursor form before, I assume it is supposed
to entail the combination of shape and color? I couldn't see the term
explicitly introduced anywhere.

-- 
Mikael Magnusson