Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160708104729.ZM27890@torch.brasslantern.com>
Date: Fri, 8 Jul 2016 10:47:29 -0700
In-Reply-To: <55898.1467933681@hydra.kiddle.eu>
Comments: In reply to Oliver Kiddle <okiddle@yahoo.co.uk>
        "Re: tab completion color inversion" (Jul  8,  1:21am)
References: <CACW6SB6sRKdtsbFe_ikp1zqP3YRd9grq-xABMGutu4fRvCqM2A@mail.gmail.com> 
	<49130.1467902941@hydra.kiddle.eu> 
	<160707100125.ZM23567@torch.brasslantern.com> 
	<55898.1467933681@hydra.kiddle.eu>
To: zsh-workers@zsh.org
Subject: Re: tab completion color inversion
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Jul 8,  1:21am, Oliver Kiddle wrote:
}
} You can get the same, completion altering attributes
} effect, with PROMPT='%S%U%Bhello%b '

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.

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.

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

} 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.

} 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.