From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21954 invoked from network); 24 Oct 2020 01:34:36 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 24 Oct 2020 01:34:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:cc:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=8GeT5BwTRrELRM3pg6f11C9D41kF22Ze4/9tuK+ePHA=; b=vqZD777Yv7ADf2GEm2h0ZfLVCh Xp1b/aD+qAp3hYA7Wt0fJnFpQ/1VnXoctCH1dP3bAFuTmKK4LV8wOvtaC46c30QpBXivbW0hccY5m 6nvAY1jbvO0WnF8DLFHwsHGEYOd0cuvzI5kzSwJiqFLR3N7A8XlwBs6gfSDRbD/wjzfOd3BDdTjtL i35wdbUtLmSncHNToqt5NAit9IZ/peA1p6O/p6bCMdSAJZvxAyolnkDhRWlkryUQUbZOraeAun8RU 2g4WZIFluSG9ZWTkfyPAszM7dDjbi/y6cBKtywX33/auRnegCSEyF3T1jmmtH57yxVG+vgQ4watZo 2eanvUnw==; Received: from authenticated user by zero.zsh.org with local id 1kW8Ry-000Lw9-4y; Sat, 24 Oct 2020 01:34:30 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1kW8Rf-000LnI-QW; Sat, 24 Oct 2020 01:34:12 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1kW8Rf-0009Bt-5O; Sat, 24 Oct 2020 03:34:11 +0200 cc: Marlon Richert , Zsh hackers list In-reply-to: From: Oliver Kiddle References: <0B36073E-6BF5-4C42-B591-1573FEC2AFA8@gmail.com> To: Roman Perepelitsa Subject: Re: region_highlight converts `fg=default` to `none`, which is not the same MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35331.1603503251.1@hydra> Date: Sat, 24 Oct 2020 03:34:11 +0200 Message-ID: <35332-1603503251.163773@XMcg.z-U3.rG9f> X-Seq: 47491 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: On 15 Oct, Roman Perepelitsa wrote: > It's premature to say I'm going to extend the spec syntax. Just > thinking out loud, looking for feedback. > > That said, extra ANSI attributes would be useful. My first choice > would be italic. The biggest problem with adding it is that zattr > doesn't have free bits left, so adding just one extra one/off > attribute would require changing the type of zattr from uint64_t to > some kind of struct, which would in turn require sweeping code changed > because zattr is used in so many places as an argument to bitwise > operators. I've spent a full day on this a few months back and > eventually stashed the change. Such changes can be tricky and it might be better to look for ways to eke out a couple more bits from a 64-bit zattr. We do use a big array of them for storing display contents so making zattr bigger isn't entirely ideal. Three possibilities come to mind :- (1) TXT_ATTR_{B,F}G_TERMCAP which is holding meta information rather than text attributes. (2) Having both OFF and ON bits for attributes. One bit ought to suffice - text is either in bold or it isn't. (3) You could put TXTFGCOLOUR/TXTBGCOLOUR in a high bit of TXT_ATTR_FG_COL_MASK when TXT_ATTR_FG_24BIT is not set. Regarding (1), I just noticed that a new D01prompt test case is failing on FreeBSD because ${(%):-%F{2}} is not producing the same as ${(%):-%F{green}}. This is a new test added just last month in 47352. This is down to TXT_ATTR_FG_TERMCAP being set for 2 but not for green. I'm inclined to think that when we parse a colour is not the right place to decide whether we want to use termcap or not. Leave that for the code which generates the escape sequences. The decision to not trust termcap for named colours comes from 24957. I've no idea what the rationale for that might be. The use of termcap or otherwise has no bearing on whether it'll really be green. I doubt there'd be much harm in dropping those two flags, or does anyone see an issue? Or remember historical reasoning? This would be the easiest way to get two bits for italics. I just did a trial of code changes for (2). The existing code does set, e.g. both TXTFGCOLOUR and TXTNOFGCOLOUR on particular elements. The turning off of attributes seemingly comes after the character. So my trial is turning attributes off one position early but otherwise breaks surprisingly little given the quite significant chunks of code that get ripped out. Not having anywhere to attach final attribute-off actions may mean this is unworkable. Does anyone more familiar with the code have any ideas on what this might break? Being able to leave attributes on at the end of the prompt comes to mind but it may also affect some aspect of manipulating the zle buffer. I expect the original reason for having both OFF and ON flags was that the earliest code using this was the parsing of prompt %-escapes for which the distinction between off, on and unchanged is needed. So an additional mask for changes would have added complexity. But for the zle display code, changing it might make the code simpler. One little xor in settextattributes() is able to derive changes since the last attributes. But it may prove far from trivial to hammer out whatever tricky incompatibilities it does throw up. I may persevere with this somewhat. Partly because I see potental for the refactoring to simplify the code significantly. But I'd be interested in any thoughts or insight anyone might have. (3) would require some tweaks to the bit twiddling. Note that TXTFGCOLOUR and TXTBGCOLOUR are needed, in effect to represent [not] the default colour. I'd only do this after trying the first two but it does free an extra two bits reasonably easily. > Another obstacle to supporting more ANSI attributes is the shortage of > upper- and lowercase letters that can be used in prompt expansions > (similar to %B/%b and %U/%u for bold and underlined). It would be a > shame if it was possible to use italic/faint/conceal in > region_highlight but not in prompt. If it comes to it, %A{faint}. I'm sure this was discussed once before. Oliver