zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Roman Perepelitsa <roman.perepelitsa@gmail.com>
Cc: Marlon Richert <marlon.richert@gmail.com>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: region_highlight converts `fg=default` to `none`, which is not the same
Date: Sat, 24 Oct 2020 03:34:11 +0200	[thread overview]
Message-ID: <35332-1603503251.163773@XMcg.z-U3.rG9f> (raw)
In-Reply-To: <CAN=4vMrhFNOF7-Zk5njFq=5guk=wTx27XBkc7BSnY4Aw23bWyQ@mail.gmail.com>

On 15 Oct, Roman Perepelitsa wrote:
> It's premature to say I'm going to extend the spec syntax. Just
> thinking out loud, looking for feedback.
>
> That said, extra ANSI attributes would be useful. My first choice
> would be italic. The biggest problem with adding it is that zattr
> doesn't have free bits left, so adding just one extra one/off
> attribute would require changing the type of zattr from uint64_t to
> some kind of struct, which would in turn require sweeping code changed
> because zattr is used in so many places as an argument to bitwise
> operators. I've spent a full day on this a few months back and
> eventually stashed the change.

Such changes can be tricky and it might be better to look for ways to
eke out a couple more bits from a 64-bit zattr. We do use a big array of
them for storing display contents so making zattr bigger isn't entirely
ideal.

Three possibilities come to mind :-
 (1) TXT_ATTR_{B,F}G_TERMCAP which is holding meta information rather
     than text attributes.
 (2) Having both OFF and ON bits for attributes. One bit ought to
     suffice - text is either in bold or it isn't.
 (3) You could put TXTFGCOLOUR/TXTBGCOLOUR in a high bit of
     TXT_ATTR_FG_COL_MASK when TXT_ATTR_FG_24BIT is not set.

Regarding (1), I just noticed that a new D01prompt test case is failing
on FreeBSD because ${(%):-%F{2}} is not producing the same as
${(%):-%F{green}}. This is a new test added just last month in 47352.

This is down to TXT_ATTR_FG_TERMCAP being set for 2 but not for green.
I'm inclined to think that when we parse a colour is not the right place
to decide whether we want to use termcap or not. Leave that for the code
which generates the escape sequences. The decision to not trust termcap
for named colours comes from 24957. I've no idea what the rationale for
that might be. The use of termcap or otherwise has no bearing on whether
it'll really be green.

I doubt there'd be much harm in dropping those two flags, or does anyone
see an issue? Or remember historical reasoning?
This would be the easiest way to get two bits for italics.

I just did a trial of code changes for (2). The existing code does set,
e.g. both TXTFGCOLOUR and TXTNOFGCOLOUR on particular elements. The
turning off of attributes seemingly comes after the character. So my
trial is turning attributes off one position early but otherwise breaks
surprisingly little given the quite significant chunks of code that get
ripped out. Not having anywhere to attach final attribute-off actions
may mean this is unworkable. Does anyone more familiar with the code
have any ideas on what this might break? Being able to leave attributes
on at the end of the prompt comes to mind but it may also affect some
aspect of manipulating the zle buffer.

I expect the original reason for having both OFF and ON flags was that
the earliest code using this was the parsing of prompt %-escapes for
which the distinction between off, on and unchanged is needed. So an
additional mask for changes would have added complexity. But for the zle
display code, changing it might make the code simpler. One little
xor in settextattributes() is able to derive changes since the last
attributes. But it may prove far from trivial to hammer out whatever
tricky incompatibilities it does throw up.

I may persevere with this somewhat. Partly because I see potental
for the refactoring to simplify the code significantly. But I'd be
interested in any thoughts or insight anyone might have.

(3) would require some tweaks to the bit twiddling. Note that
TXTFGCOLOUR and TXTBGCOLOUR are needed, in effect to represent [not] the
default colour. I'd only do this after trying the first two but it does
free an extra two bits reasonably easily.

> Another obstacle to supporting more ANSI attributes is the shortage of
> upper- and lowercase letters that can be used in prompt expansions
> (similar to %B/%b and %U/%u for bold and underlined). It would be a
> shame if it was possible to use italic/faint/conceal in
> region_highlight but not in prompt.

If it comes to it, %A{faint}. I'm sure this was discussed once before.

Oliver


  parent reply	other threads:[~2020-10-24  1:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12  9:22 Marlon Richert
2020-10-13 11:05 ` Roman Perepelitsa
2020-10-14  5:12   ` Marlon Richert
2020-10-14 20:46   ` Daniel Shahaf
2020-10-15  7:37     ` Roman Perepelitsa
2020-10-15 16:58       ` Marlon Richert
2020-10-15 17:09         ` Roman Perepelitsa
2020-10-16 13:36           ` Daniel Shahaf
2020-10-24  1:34           ` Oliver Kiddle [this message]
2020-10-24  6:42             ` Roman Perepelitsa
2020-10-16 13:28       ` Daniel Shahaf
2020-10-16 15:50         ` Bart Schaefer
2020-10-22 19:58           ` Marlon Richert
2020-10-22 23:28             ` Daniel Shahaf
2020-10-23  8:08             ` Roman Perepelitsa
2020-10-23  9:24               ` Marlon Richert
2020-10-23  9:35                 ` Roman Perepelitsa
2020-10-23 10:40                   ` Marlon Richert
2020-10-23 11:38                     ` Roman Perepelitsa
2020-10-24  0:50                       ` Functions/Misc/colors vs. region_highlight Bart Schaefer
2020-11-03 18:54                         ` Marlon Richert
2020-11-03 23:45                           ` Bart Schaefer
2020-11-04 15:47                             ` Marlon Richert
2021-04-18 21:40                         ` Bart Schaefer
2020-10-23 23:57                   ` Threading across year boundaries (was: Re: region_highlight converts `fg=default` to `none`, which is not the same) Daniel Shahaf
2021-03-31  8:26       ` region_highlight converts `fg=default` to `none`, which is not the same Marlon Richert
2021-04-10 20:33         ` Lawrence Velázquez
2021-04-13 15:20           ` Daniel Shahaf
2021-04-13 20:33             ` Roman Perepelitsa
2021-04-14 11:04               ` Daniel Shahaf
2021-05-09 20:49                 ` Lawrence Velázquez
2021-05-31  1:16                   ` Lawrence Velázquez
2021-03-31  8:24   ` Marlon Richert

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=35332-1603503251.163773@XMcg.z-U3.rG9f \
    --to=opk@zsh.org \
    --cc=marlon.richert@gmail.com \
    --cc=roman.perepelitsa@gmail.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).