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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22215 invoked from network); 21 Dec 2022 16:47:09 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 21 Dec 2022 16:47:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; 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=uXitw5dnSCeWRGZWasNeneIfziKnKAeYajmvIcPg1k8=; b=mvml06GceaIsVMsiiqh7mZwgbX smpGw/yltyj/7/TmiEM++FyTZs0Y6qCBuFhUir+44pcYgA6MD9Y7L5b3+R3Qu920JU0kc7eEMBBQm fxNFWtlixGcBEy2EpKdhok95RKHS3SUR7L53qr3fvI7mtgle5pSJou+PCV6jaak/9WGx/m6jPLeYc 39ezoZO3ljnlk+OfZJfubaqPa6qCSdZX9OeeulxtBCV0v+0lwj7pIjlXdQO0Azr3DAJO7cUFoZ2c+ tbr7Zh7hAlR0OBVBiSuRM4VlwzEaO2DdM1G4OcgnxakoTjYfdSeu2XsfhHqBFBdYwllFFi7PNFijd nWbLn36g==; Received: by zero.zsh.org with local id 1p82FJ-000G95-2p; Wed, 21 Dec 2022 16:47:09 +0000 Received: by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1p82Ej-000FpY-OX; Wed, 21 Dec 2022 16:46:33 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.95) (envelope-from ) id 1p82Ef-0008lJ-TM; Wed, 21 Dec 2022 17:46:30 +0100 cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: <37998-1671237833.378022@KQt2.DuNm.SJtt> <89232-1671270468.081657@opLX.-aX7.RvZU> To: Bart Schaefer Subject: Re: Turning display attributes on / off in prompt strings MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33683.1671641189.1@hydra> Date: Wed, 21 Dec 2022 17:46:29 +0100 Message-ID: <33684-1671641189.906535@VXy1.awnj.CFc3> X-Seq: 51244 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: On 17 Dec, Bart Schaefer wrote: > On Sat, Dec 17, 2022 at 1:47 AM Oliver Kiddle wrote: > > > > Bart Schaefer wrote: > > > the present prompt code would still emit the > > > then-unnecessary sequences to restore the other attributes. > > > > It's probably not worth replacing the escape sequence without also > > allowing it to avoid that because the original problem would only be > > partially solved. > > Hm, I was thinking of it more as a new problem of optimization (we go > to some lengths in other places to send the shortest possible control > sequences). In what way would the original problem not be solved? An > attribute might be turned back on after having been turned off? The original problem was due to mixing raw sequences with prompt sequences, right? Any time we produce \e[0m we lose everything from the raw sequences. We could do more to send the shortest possible control sequence. Something like %u in a prompt will always send the off sequence regardless of whether underline was previously on. If we optimise that, we actually make the situation worse for mixtures: underline on might have been done as a raw sequence. The only way to really solve that would be to parse the raw sequences. If you search for TSC_DIRTY in prompt.c, you'll see that we restore other attributes after not only bold off but for all of %s, %u, %B and, of course %b. This code path is only used for prompts. You can see this in the output of: print -P '%Sone%utwo'|sed -n l The zle code does things differently. It only restores other attributes where the use of bold ends. The implementation there is rather cleaner in my opinion. settextattributes() is passed a zattr parameter for all desired attributes and compares against the existing known state. Simply by handling TXTNOBOLDFACE first, it ensures others are restored. It'd be good to use the same interface for prompts, preferably also dropping the "NO" forms of the flags to free up some bits to add more attributes. The glitch handling using the "sg" and "ug" termcap sequences also seems to only be done for prompts but not ZLE. Do you know more about this? Can it also be condemned to ancient history? To optimise the control sequences to the maximum, generating sequences should be delayed until actual text is printed but that either needs to be added in many places or the output routines need to be wrapped. Are there other control sequences that the current attributes affect (scrolling up perhaps)? > Hm, that's a bit more heavyweight than I was thinking, but would be > the most flexible. It is heavyweight but it already exists. I don't think the tc interface itself is ideal because it is too low-level. Extending the interface with something like zle -T attr doesn't necessarily need to be followed by a function. It's a question of what sort of interface would be useful? I think it would be best if we can assume a modern terminal (i.e. just use \e[22m) but allow old or broken terminals to be worked around from a shell interface. The hard part is designing that interface. > I presume you mean to move the transformation to the main shell and > have zle call it? Loading zle in non-interactive context would be > less desirable? The zle module could register a callback which the main shell would call when changing attributes. Or it could be moved to a separate module. > > * \e[22m selects normal, disabling also faint so naming indicating end > > of bold would be a poor choice. > > That's true, outside of prompt context (which doesn't currently have a > way to express "faint" without using raw sequences). But all the > other attributes are additive whereas faint/normal/bold are mutually > exclusive even at the terminal level, we're not going to be able to > make a general solution for (faint on)(bold on)(bold off) that ends in > (faint on) state. If you consider double underline, underline no underline or slow blink, rapid blink, no blink then the font weight is not actually unique in this regard. It wouldn't be a good idea for a variety of reasons but you could in theory have: %bfaint%Bnormal%Bbold While less terse, it is probably wiser to go with: %A{faint}faint%A{normal}normal%Bbold Oliver