Re: Suggested improvement for sticky-note

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Just now getting back to this ...

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

> adds options for selecting a background colour &/or blinking when creating a new sticky note, and automatically adds the appropriate escape codes. It also adds a help option.

There are a few reasonable suggestions here mixed with quite a number
of things that could be improved.  Adding noflowcontrol to the setopts
is probably a good idea, and passing "-e" to vared should at least be
configurable.  That also caused me to notice that interrupting
sticky-note with a keyboard interrupt (^C) can cause old notes to
disappear, so that should be fixed.  Help text is good if other new
command-line options are coming.

On the flip side:

The ad-hoc option recognition by pattern-matching "$*" is going to be
error prone.  Previously all the options were mutually exclusive so
just testing $1 was OK, but if there are going to be several options
that can appear in combination there ought to be a call to zparseopts
(or at least getopts).

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?

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.

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.

It's going to take a bit more thought to decide what it's possible to
salvage from this, so no patch yet.

For any other zsh-workers reading this:  Does anyone know why
putpromptchar() has this?
            case 'b':
                txtchangeset(txtchangep, TXTNOBOLDFACE, TXTBOLDFACE);
                txtunset(TXTBOLDFACE);
                tsetcap(TCALLATTRSOFF, TSC_PROMPT|TSC_DIRTY);
                break;
That is, why TCALLATTRSOFF ?  That isn't done for %s or %u ... why is
there no TCBOLDFACEEND defined?