Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
In-reply-to: <160708104729.ZM27890@torch.brasslantern.com>
From: Oliver Kiddle <okiddle@yahoo.co.uk>
References: <CACW6SB6sRKdtsbFe_ikp1zqP3YRd9grq-xABMGutu4fRvCqM2A@mail.gmail.com> <49130.1467902941@hydra.kiddle.eu> <160707100125.ZM23567@torch.brasslantern.com> <55898.1467933681@hydra.kiddle.eu> <160708104729.ZM27890@torch.brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: tab completion color inversion
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <64905.1468015236.1@hydra.kiddle.eu>
Date: Sat, 09 Jul 2016 00:00:36 +0200
Message-ID: <64906.1468015236@hydra.kiddle.eu>

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