Re: Suggested improvement for sticky-note

[vapnik spaknik <vapniks@xxxxxxxxx>]

> On Sunday, May 9, 2021, 09:50:18 PM GMT+1, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

>> On Mon, May 3, 2021 at 7:06 PM vapnik spaknik <vapniks@xxxxxxxxx> wrote:
>>
>> The attached diff (against the original)

> ... is still a file with the ".diff" suffix instead of ".txt" ...

oops, sorry

> .....
> Hardwiring two options for color and blink seems pretty arbitrary
> (compare the "escapes" style in my patch that selects among three
> variants).  What if someone wants italics or boldface or underlining
> instead of blinking?

I thought most people would only need to differentiate different categories of notes (colours), and important ones (blinking), but I guess blinking might be a bit annoying for some.

> It's a bit strange to use $(echoti blink) for "on" but then hardwire
> $'\e25m' for "off".  Anyway, $(echoti blink) just spits out an error
> on my terminal, which the patch doesn't account for.

I thought echoti would be more portable, obviously I was wrong, but couldn't find any echoti command to turn off blinking.

> Having the note blink while it is being edited is rather
> weird/distracting even if you want it to blink when displayed later.
> (There's a reason web browsers dropped support for the HTML <blink>
> tag, but we won't go there.)  Also, during editing the visual changes
> are part of the vared prompt, but then are stored as raw ANSI escapes
> in the text of the sticky note itself, which will have odd
> side-effects when using history to access previous notes.

> This is a mixing of metaphors, so to speak.  Visual changes are in the
> text but the interpretation of bindkey sequences is done by "print -b"
> after the text is read back from the file and is being displayed.
> Even so, the raw escapes only work when combined with your -B option,
> because if "print -b" is not used, the ASCII 033 are converted to "^"
> "[" before being sent to the terminal.

> Finally, you've embedded the definition-time theme color in the note
> at the point where blink is turned off, so if the theme changes (new
> zstyle applied) any notes that had color changes or blink will revert
> to the previous theme's coloring.  In fact this makes me aware that it
> doesn't really work to interpret prompt escapes, because (for example)
> after %Bbold%b the background color reverts as well and the rest of
> the note is no longer yellow.

Seems I overlooked a few things when I hacked that up a few days ago.
It did cross my mind to use getopts, but I thought it would be better to keep 
the code short, and not make too many changes.
The patched sticky-note works for my purposes, but if I get some time at some 
point in the future (can't say when) I will have another look at it, unless you beat me to it..