zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Turning display attributes on / off in prompt strings
Date: Wed, 21 Dec 2022 17:46:29 +0100	[thread overview]
Message-ID: <33684-1671641189.906535@VXy1.awnj.CFc3> (raw)
In-Reply-To: <CAH+w=7abhbe-+oXG75m-KK6UCrW6_PVFLmNK_jJu0LUD8Nt2Pw@mail.gmail.com>

On 17 Dec, Bart Schaefer wrote:
> On Sat, Dec 17, 2022 at 1:47 AM Oliver Kiddle <opk@zsh.org> wrote:
> >
> > Bart Schaefer wrote:
> > > the present prompt code would still emit the
> > > then-unnecessary sequences to restore the other attributes.
> >
> > It's probably not worth replacing the escape sequence without also
> > allowing it to avoid that because the original problem would only be
> > partially solved.
>
> Hm, I was thinking of it more as a new problem of optimization (we go
> to some lengths in other places to send the shortest possible control
> sequences).  In what way would the original problem not be solved?  An
> attribute might be turned back on after having been turned off?

The original problem was due to mixing raw sequences with prompt
sequences, right? Any time we produce \e[0m we lose everything from
the raw sequences. We could do more to send the shortest possible
control sequence. Something like %u in a prompt will always send the
off sequence regardless of whether underline was previously on. If
we optimise that, we actually make the situation worse for mixtures:
underline on might have been done as a raw sequence. The only way to
really solve that would be to parse the raw sequences.

If you search for TSC_DIRTY in prompt.c, you'll see that we restore
other attributes after not only bold off but for all of %s, %u, %B and,
of course %b. This code path is only used for prompts. You can see this
in the output of:
  print -P '%Sone%utwo'|sed -n l

The zle code does things differently. It only restores other attributes
where the use of bold ends. The implementation there is rather cleaner
in my opinion. settextattributes() is passed a zattr parameter for all
desired attributes and compares against the existing known state. Simply
by handling TXTNOBOLDFACE first, it ensures others are restored.
It'd be good to use the same interface for prompts, preferably also
dropping the "NO" forms of the flags to free up some bits to add more
attributes.

The glitch handling using the "sg" and "ug" termcap sequences also seems
to only be done for prompts but not ZLE. Do you know more about this?
Can it also be condemned to ancient history?

To optimise the control sequences to the maximum, generating sequences
should be delayed until actual text is printed but that either needs
to be added in many places or the output routines need to be wrapped.
Are there other control sequences that the current attributes affect
(scrolling up perhaps)?

> Hm, that's a bit more heavyweight than I was thinking, but would be
> the most flexible.

It is heavyweight but it already exists. I don't think the tc interface
itself is ideal because it is too low-level. Extending the interface
with something like zle -T attr doesn't necessarily need to be followed
by a function. It's a question of what sort of interface would be
useful? I think it would be best if we can assume a modern terminal
(i.e. just use \e[22m) but allow old or broken terminals to be worked
around from a shell interface. The hard part is designing that
interface.

> I presume you mean to move the transformation to the main shell and
> have zle call it?  Loading zle in non-interactive context would be
> less desirable?

The zle module could register a callback which the main shell would call
when changing attributes. Or it could be moved to a separate module.

> > * \e[22m selects normal, disabling also faint so naming indicating end
> > of bold would be a poor choice.
>
> That's true, outside of prompt context (which doesn't currently have a
> way to express "faint" without using raw sequences).  But all the
> other attributes are additive whereas faint/normal/bold are mutually
> exclusive even at the terminal level, we're not going to be able to
> make a general solution for (faint on)(bold on)(bold off) that ends in
> (faint on) state.

If you consider double underline, underline no underline or slow
blink, rapid blink, no blink then the font weight is not actually
unique in this regard. It wouldn't be a good idea for a variety of
reasons but you could in theory have:

  %bfaint%Bnormal%Bbold

While less terse, it is probably wiser to go with:

  %A{faint}faint%A{normal}normal%Bbold

Oliver


  reply	other threads:[~2022-12-21 16:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 19:45 Bart Schaefer
2022-12-17  0:43 ` Oliver Kiddle
2022-12-17  7:50   ` Bart Schaefer
2022-12-17  9:47     ` Oliver Kiddle
2022-12-17 19:45       ` Bart Schaefer
2022-12-21 16:46         ` Oliver Kiddle [this message]
2022-12-21 21:28           ` Bart Schaefer
2022-12-21 17:12 ` Oliver Kiddle
2022-12-21 21:03   ` Bart Schaefer

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=33684-1671641189.906535@VXy1.awnj.CFc3 \
    --to=opk@zsh.org \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).