Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: tab completion color inversion
- X-seq: zsh-workers 38814
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: tab completion color inversion
- Date: Sat, 09 Jul 2016 00:00:36 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1468015237; bh=feiMHpd9xBOLQEyCgOI73oHBkbMUgDu9N201fKU4yrc=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=KGE9uYGVvLHIxmlIqJbVgJNHwg/g0+w5KYLegyp3UV2BVO3B7vvhkT/KGzRIBbK/2UxJJG+krMaGxF7y8o9taCAiFe7b07TAcGr3yzdepUNYFP0EX3kuLjct9kSf2Z3KjRkn/qCgE7gZ/gzXIUmXuRyDZ2lzDRvTCHE9kqgGu8fTZrR+NYPqT55Le2ZIYXZ4z9ZVAc+fj9/T/wbAcqFxEfzHi0c5mM3V3D2h4uhSCUcCfiBC9LJbjFskRMgdAVT36eiWH5kbj55903sHWTfHbRVeiDNzoymmumSR4GymKIPKdUO7JGSgMLAL3bLzZh4hesf2xBgKsCsJhVgXyhUBFQ==
- In-reply-to: <160708104729.ZM27890@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- 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>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author