From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25272 invoked by alias); 23 Feb 2015 00:17:18 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19890 Received: (qmail 20530 invoked from network); 23 Feb 2015 00:17:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_FSL_HELO_BARE_IP_2 autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1424650218; bh=ocMoJl/K8j7Ija26r6unlWbufm92zJ7VGtR9uzFHGNw=; h=From:To:In-Reply-To:References:Subject:Date; b=R6+xrnL3gxZJAt7GwHnl1siiXoCQQ0CMds4vaYxIA3O/i/MpR65ZgvNT4XM6fOBkX K3Fixawje96HAbJGLTlq9R5YuS0s3gnDuj2zxILEn0nVAevd/Dr6lz/h40JsKUy69e 3Vywr7qGp7C7z9+JqbttTDiIoLksuWMjnXl3Vq0M= From: ZyX To: Ray Andrews , "zsh-users@zsh.org" In-Reply-To: <54EA6200.1040007@eastlink.ca> References: <20150222132310.GA18377@wintermute> <150222111007.ZM18687@torch.brasslantern.com> <54EA6200.1040007@eastlink.ca> Subject: Re: ANSI bg colour outside of prompt area MIME-Version: 1.0 Message-Id: <4348921424650217@web10g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 23 Feb 2015 03:10:17 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 23.02.2015, 02:43, "Ray Andrews" : > On 02/22/2015 11:10 AM, Bart Schaefer wrote: >>  } In zsh, the background color gets reset once the characters have been >>  } printed. >> >>  That's intentional so that a misbehaving program can't e.g. cause your >>  prompt to become invisible by changing the background to the same color >>  as your prompt foreground. > > That makes sense, and I suppose, as you say, the more direct thing is to > manipulate the terminal, tho that means a restart anytime you wanted one > of those color changes, and my xfce4-terminal doesn't seem to permit > command line color changes anyway.  But to the extent that zsh supports > color, shouldn't the colors stay set until they are explicitly changed? > I see in bash: > > echo -e "\e[41m" > red > red > red > echo -e "\e[0m" > normal > normal > normal > > I get exactly what I ask for--when I want to return to defaults, I say so. > > So, would it be possible to have, say, an option to stop ZLE from > clearing the screen as it does?  I can see that the zsh way is safer, > but being able to turn it off sounds like a cool option as well, and > friendly to our bash converts besides. It is the first time I saw any “bash convert” needing this feature. I think that if you create a poll you will see that almost everybody will vote for either “WTF are you talking about?”, “Who may need this behaviour?” or “Sure, this option is cool. Doesn’t mean I am going to ever use it though.” I have tested `echo $'\e[41m' ; {command}` with the following colored commands and here is what I have: eix | First line has red background after the text, to the very end. hg diff | Same. git diff | First line has text with red background, red ends as text ends. grep | First file name has red background (multifile search) and nothing | after it. Single file match has highlight up until the first match | ends (match is highlighted). ag | Again red background ends when the first highlighted string ends. powerline | Red background appears on the first line and disappears completely | when powerline outputs something. No color program I know bothers to stop its highlighting any way other then catch-all `\e[0m` or similar `\e[m`, so to use this feature you should disable colors. Many terminals support changing background color via escape sequences like the one from my first message (st appears not to support this, but it even has no scrollback buffer, so it is not surprising). This leaves very little space in which feature may be considered useful and cannot be implemented the other way. Thus I would say that implementing such option is a pure waste of time.