From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4810 invoked by alias); 8 Jul 2016 22:07:09 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38814 Received: (qmail 7752 invoked from network); 8 Jul 2016 22:07:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 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== X-Yahoo-Newman-Id: 398604.93380.bm@smtp125.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .nG6PQkVM1mOysAhkr0M.lrCyyoBtRLcIh8rCMrCqgn1uDJ egmROZIE_y9VQhaOqZgUSf6YF8xSBv08YyZ1mayctglVCq9yoYIQX1FLjATy muBjYBhy5hBhg5nwTzFyJw0vIVYC9U9AAUqerQslOlNzS5UMPvYqIjMdQ2w7 Z8dybH9djQQmuvVtMz0lYhb3MdZwMk_GkKPBP.kkkHksa5lLkv9VthZKpDDM s08nrvaQ_D7gYXSKvnKkEqMDp.5EwZZop63pdAHdDUSkT2H5UuLU8_YMBF2V XLWHP3H7WM1LvL0v.mb2z1Uf9teLvMJW4cRERrAiTn5dt6bjkFEx039N83L1 KVSVMxA.pTmdHvM6iWM9M3YaTdV0kO0Ql90FuFlfbY294cdfeIXNEgWe8xsb SByms.2qlQKMHJtfwff.n7WREWjT7ICGA.BQFvGO4.ARjxiZa5x.TJvuZesR rbl.5GwAYn34lvfIn_OQ_.eOWJ58AQb5grFlOaAa8o7Um64o3GtBo_AylJ.3 CYd.GMqJCJeZETLHsevOi.4qURS1kxxYjFlf8e8g8b8Y- X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: <160708104729.ZM27890@torch.brasslantern.com> From: Oliver Kiddle References: <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