Re: PATCH: alternate views on .zle.hlgroups

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

I don't do much with zle_highlight so I have only general comments ...

On Sun, Feb 11, 2024 at 9:26 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> This implementation uses dupstring() to return memory from the parameter
> string get function.

The unset functions generally expect to free the memory from the
parameter value, but since these are readonly specials it's probably
safe to use the heap (see below).  I don't know what oddities might
arise from declaring a "local +h" on these names.

> Would be good to have
> confirmation from someone who has a clearer understanding of what the
> lifetime of the memory pools is.

There can be a stack of pools so the one that gets used will be the
one that's active at the time the parameter is referenced.  Assigning
the value to another parameter will copy the value, not point to it,
so the only iffy bit is whether the getfn refreshes the u.str pointer
every time the variable is referenced.

I believe there's a new pool during zle widgets, for example, so if
you reference one of these both inside a call to "zle
user-defined-thing" and then again after zle returns, this could be
tickled.

> My second thought was support for parsing terminal responses to the
> escape sequence for getting the background colour. [...]
> very helpful to avoid unreadable colour combinations. What form should
> this best take? A builtin? Having a key bound to \e]11;rgb: may be
> the best way to avoid interference with a type-ahead buffer but that
> inconveniently move the setup code to a zle widget. ungetc() in C may
> work better than my current print -z solution, especially where some of
> the typeahead text is not even intended for zsh.

The shell input is unbuffered** and managed by the shell itself, so I
don't know if ungetc() works at all.  There are no calls to ungetc
remaining in Src/*.c, they all use either ihungetc() or inungetc() via
the hungetc code pointer.  So I think if there's input not intended
for zsh you, either mustn't read it at all or there's nothing you can
do about it.

I'd use "zle -U" rather than "print -z" (or choose one or the other
based on context if "zle -U" isn't always usable at the time).  I
suppose you do need to account for -U being LIFO, but -z is the buffer
stack so popped one entry at a time so probably also won't do the
right thing if called more than once successively.

**Where support-able, else line buffered.