zsh-workers
 help / color / mirror / Atom feed
From: vapnik spaknik <vapniks@yahoo.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Hackers List <zsh-workers@zsh.org>
Subject: Re: Suggested improvement for sticky-note
Date: Tue, 11 May 2021 12:37:18 +0000 (UTC)
Message-ID: <734416914.95418.1620736638811@mail.yahoo.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 <schaefer@brasslantern.com> wrote:

>> On Mon, May 3, 2021 at 7:06 PM vapnik spaknik <vapniks@yahoo.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..



      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] <1185563186.165566.1619896723304.ref@mail.yahoo.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
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 \
    --in-reply-to=734416914.95418.1620736638811@mail.yahoo.com \
    --to=vapniks@yahoo.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.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 \
		zsh-workers@zsh.org
	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