Re: tab completion color inversion

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Bart wrote:
> Presumably it's intentional that reaching the end of the prompt string
> does not implicitly reset all the %S %U etc. attributes?  E.g., meant
> to be combined with ( preexec() { print -nP %u%s } ) or similar.

This was never done in the past. And until we had zle_highlight it
was necessary if you wanted different attributes for the text you
entered and for command output. Completion has spoiled that concept
since long ago, however:

> Using that prompt I can still get effects where the %S%U ends in the
> middle of a command line after completing.  I don't think this is a
> bug, per se, because leaving the attributes hanging open like that is
> not exactly documented behavior, but it might argue that they should
> be implicitly turned off.

We should probably treat it as a bug if we can track it down. For
backward compatibility, I'm inclined to think that whatever is
leftover after PS1 should be used as a default if zle_highlight
doesn't give something more explicit. Using zle_highlight does seem
to work together with completion.

Note also that txtattrmask is not reset between invocations of print -P
which is useful in some cases but not in others. Try this:
  print -P '%S' >/dev/null; print -P '%bhello'

> (I think completion always resets the attributes, but sometimes ZLE
> reprints the whole prompt which turns them back on again.)

Completion sometimes restores the attributes and sometimes resets them.

> } txtchangep and txtattrmask seem to be doing much the same thing -
> } tracking the current attributes. The need for tracking attributes that
> } have been turned off such as TXTNOBOLDFACE seems a bit odd - wouldn't
> } the absence of TXTBOLDFACE do the job?
>
> You've stated most of my confusion over this, quite succinctly.  My
> only guess is that one represents a temporary state change from the
> more persistent state of the other, but I haven't worked out how that
> plays or which is which.

Yes, TXTNOBOLDFACE only makes sense if recording relative attribute
changes. Quite how that's useful, I'm not sure. If attributes are
tracked, a simple XOR with desired attributes gets you what needs
changing.

> } I've not done that then but I did put the AND before the OR.
>
> In thinking about this further, swapping the AND and OR subexpressions
> does change the semantics when the same bit is present in both X and Y.
> Maybe that never comes up.

It doesn't. I did grep for it and that case only came up for the colours
which is where we want AND first.

Oliver