Re: region_highlight converts `fg=default` to `none`, which is not the same

[Oliver Kiddle <opk@xxxxxxx>]

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