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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Mar 30, 2024 at 5:23 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Bart Schaefer wrote:
> > No, but I was planning to commit 52314 if any feedback were provided
>
> 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.

There's no need for backward compatibility at this point, as that has
never gone anywhere except into 52314.  That implementation can be
scrapped and replaced with zle_highlight -compatible constructs.

The more complicated issue is how to apply the highlighting when doing
"list the existing sticky notes", because ZLE is not involved there.
I guess if it's limited to styling the entire note rather than
individual words, I only need the starting and ending %-expandos, if
there's an easy way to extract that from the $zle_highlight value.

> The purpose of the display style might have been easier to follow if
> you had used keys with names like urgent, later, work

I was copying the names originally proposed back in vapnik spaknik's
"Suggested improvement" thread (May 2021).

> [...]  as %s turns off standout, %d or %n may be
> better.

Could also just use a parameter interpolation, e.g. ${.zsticky.note}
... I used %s so that it could be passed to printf but that's not
really necessary, especially if I rewrite with ${|...}.

> I'd also be inclined to make use of the zstyle context, e.g.:
>
>   zstyle ':sticky-note:urgent' display '%H{urgent}<<< %d >>>'

That's complicated when it comes to listing out the possible context
choices for completion in _sticky_displays.  Suggestions?

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

This should be changed to use zstyle -q at the very least.  Hadn't got
there yet.

> 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

If you've entered sticky-display with ^X? then you need one ^M to get
out of that and then two more rapidly to finish the note.  Does that
explain what you see?

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

Presently you can edit an existing note but then that is appended as a
new one.  Editing old notes would have to be done with e.g. "zed -h"
which I haven't integrated yet ... and has other issues because the
history timestamps are used to match up the notes with the display
file.

Otherwise sticky-note has to be completely rewritten to avoid use of
"fc -p" for the notefile, which is not out of the question but makes
up/down "history" of notes complicated.

> Would you want blink?

I would not, but vapnik did, which what got this started.  Could there
e.g. be a zattr bit that means "the next five bytes are a custom
attribute" and then just stuff in the escape sequence directly?  I
suppose that messes with remembering how attributes overlap.

> > 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.

Perhaps a single boolean that says either to extend the background
color to the end of the line vs. reverting to the default terminal at
the end of the printable text, would be sufficient.  The only reason I
can think of for using something different would be to distinguish
trailing whitespace (i.e., where the background shows through but
there's actually something there in $BUFFER).