From: vapnik spaknik <firstname.lastname@example.org> To: Bart Schaefer <email@example.com> Cc: Zsh Hackers List <firstname.lastname@example.org> Subject: Re: Suggested improvement for sticky-note Date: Tue, 11 May 2021 12:37:18 +0000 (UTC) Message-ID: <email@example.com> (raw) In-Reply-To: <CAH+w=7Z0wO_1AgHxhsRLDcActY=YCyp1+1r-w4mJxmKDGhZM9A@mail.gmail.com> > On Sunday, May 9, 2021, 09:50:18 PM GMT+1, Bart Schaefer <firstname.lastname@example.org> wrote: >> On Mon, May 3, 2021 at 7:06 PM vapnik spaknik <email@example.com> 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..
prev parent reply other threads:[~2021-05-11 12:37 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> 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 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 ` vapnik spaknik [this message]
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 \ --email@example.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