Re: sticky-note and prompt color leftovers (Re: PATCH: broader support for highlight groups)

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> No, but I was planning to commit 52314 if any feedback were provided
> (which none has been, so far).  So please have a look a that, if you
> don't mind.

From the perspective of display attributes, that change would make it
significantly harder to adapt to using zle_highlight instead of the
colors function if you also need to maintain backward compatibility with
user style settings. In it's current form, with the associative array,
fg/bg can be mapped directly to fg= and bg= except where they have
values like bright-gray. The reset key could be ignored and the color
key would a problem.

The purpose of the display style might have been easier to follow if
you had used keys with names like urgent, later, work rather than none,
blink, reverse in the example. With the %s substitution form, prompt
strings would be more consistent with how we configure other things like
completion descriptons. And as %s turns off standout, %d or %n may be
better. I'd also be inclined to make use of the zstyle context, e.g.:

  zstyle ':sticky-note:urgent' display '%H{urgent}<<< %d >>>'

I don't personally like the existing approach of defining a style for
the fallback default. sticky-note currently does this for theme.

The recursive-edit doesn't seem to work too well, at least not starting
with my setup. I somehow need to Ctrl-C out of it. Might be related to
that ^M^M binding which is somehow hard to trigger despite KEYTIMEOUT
being generous enough. But if it works for you including with bindkey -v
then I probably need to bisect my setup.

Is there a way to remove or edit an existing note?

> > It doesn't need much more than to precede the vared with, e.g.
> >   local zle_highlight=( default:fg=black,bg=yellow )

Some of the other keys like paste, ellipsis and region may also be
applicable too.

> OK.  What about effects like underlining or blinking?

zle_highlight=( default:fg=black,bg=yellow,underline )

Would you want blink? Adding that to zle in the manner of italic and
faint would now be really easy but I didn't want to be too profligate
with the bits in zattr that got freed up in the refactoring. And my
normal terminal dropped support for blink at some point.

But given that terminals are now providing custom true-colour double
curly underline, we might have to find a way to remove the restrictions.

> > I know that when I worked on this a year ago, I had it in mind to add
> > an additional key for zle_highlight which is used for line clearing
> > allowing a background for the area on the right that doesn't contain
> > text. I can't remember whether or not it was discussed. Any thoughts on
> > the name - viewport, buffer, field?
>
> I don't recall discussion either.  How (if at all) does the PREDISPLAY
> / POSTDISPLAY text fit into this?  Would the fallback case be to match
> the bg= color or to use the terminal default background?

The background color would equally apply to those. There's no way for
widgets to control the cleared space and PREDISPLAY/POSTDISPLAY are
mostly used by widgets. This leads me to the conclusion that we would
instead need an extra key - clear, or clearbg, perhaps - so that you
would instead do:

  zle_highlight=( default:clear=yellow )

This doesn't need extra bits in zattr but would need an extra zattr for
each zle_highlight entry. I fear it would require consuming memory on a
colour for every position in the zle buffer. Perhaps, we need to think
about keeping indices into a palette instead. Maybe we can limit it to
default for now.

Oliver