From: Bart Schaefer <firstname.lastname@example.org> To: vapnik spaknik <email@example.com> Cc: Zsh Hackers List <firstname.lastname@example.org> Subject: Re: Suggested improvement for sticky-note Date: Sun, 9 May 2021 13:50:06 -0700 Message-ID: <CAH+w=7Z0wO_1AgHxhsRLDcActY=YCyp1+1r-w4mJxmKDGhZM9A@mail.gmail.com> (raw) In-Reply-To: <email@example.com> Just now getting back to this ... On Mon, May 3, 2021 at 7:06 PM vapnik spaknik <firstname.lastname@example.org> 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?
next prev parent reply other threads:[~2021-05-09 20:50 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> 2021-05-01 19:18 ` vapnik spaknik 2021-05-02 23:57 ` Bart Schaefer 2021-05-04 2:06 ` vapnik spaknik 2021-05-09 20:50 ` Bart Schaefer [this message] 2021-05-11 10:18 ` Mikael Magnusson 2021-05-14 23:40 ` Termcap and boldface (was sticky-note) Bart Schaefer 2021-05-11 12:37 ` Suggested improvement for sticky-note vapnik spaknik
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAH+w=7Z0wO_1AgHxhsRLDcActY=YCyp1+1r-w4mJxmKDGhZM9A@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
zsh-workers This inbox may be cloned and mirrored by anyone: git clone --mirror http://inbox.vuxu.org/zsh-workers # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \ email@example.com public-inbox-index zsh-workers Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.zsh.workers code repositories for the project(s) associated with this inbox: https://git.vuxu.org/mirror/zsh/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git