ANSI bg colour outside of prompt area

ANSI bg colour outside of prompt area

[junkcommander0]

Hey Guys!

This is my first ever mailing list post, please let me know if I'm doing 
this improperly!!

I was wondering if anyone has had any success setting BG colours in 
their terminal with ANSI escape sequences or with some other method.  I 
had some aliases with escape sequences that I used for bash and shell 
that would change the background colour. The colour was never reset, and 
clearing the screen would change the entire terminal's background 
colour.

	ex: 
	echo -ne "\033[1;33;43m"


In zsh, the background color gets reset once the characters have been 
printed.
	ex:
	kecho -ne "\033[1;33;43m abcdefg"


I've tried using zle_highlight, or appending to the end of PROMPT, but 
(as documented) it only colours the editeable lines in the terminal:
	ex:
	zle_highlight=(default:bg=yellow);
	PROMPT="%K%{yellow%}$PROMPT"

I also came across a neat tweak on the mailing list that allows you to 
change the colour of errors (which is neat, but still not what I'm 
looking for):
	ex:
	preexec() { echo -en "preexec () { echo -n "\033[11;43m"; }


I'm running out of steam though I hoped maybe that precmd or something 
like that might yield some results but I'm a little stuck at the moment.  
Any chance that any of you might be able to nudge me in a different 
direction?

Thanks Again,
- Will

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/22/2015 05:23 AM, junkcommander0@gmail.com wrote:
>
>
> In zsh, the background color gets reset once the characters have been 
> printed.
>     ex:
>     kecho -ne "\033[1;33;43m abcdefg"
>
>
That's interesting, zsh is so different from bash there.  One of the 
guys will have an answer for you if there is one.  Just off hand tho, 
bash seems more correct--the default colors should not be restored 
unless you restore them explicitly, I'd say.

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 22,  8:23am, junkcommander0@gmail.com wrote:
}
} I was wondering if anyone has had any success setting BG colours in 
} their terminal with ANSI escape sequences or with some other method.

If you're using a graphical desktop with terminal emulators for shell
windows, you'd typically want to do this via the emulator configuration
instead of by sending ANSI sequences.  E.g.

    xterm -fg yellow -bg black

This gives you a lot more variety of possible colors to chose from; you
can use the entire graphical color palette rather than being limited to
what the emulator defines as e.g. "bold + yellow" for ANSI.

However ...

} I had some aliases with escape sequences that I used for bash and shell 
} that would change the background colour. The colour was never reset, and 
} clearing the screen would change the entire terminal's background 
} colour.
[...]
} 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.

Also ZLE emits a "clear to end of screen" before printing the prompt to
remove anything that another program might have left behind.  This is
to keep your prompt from getting obscured by overstriking something.
However, combined with the color reset, that has the effect of restoring
the default background color for everything below the prompt position.

So the trick is to emit the clear-screen again after changing the color
in the prompt.

    PROMPT=$'%K{yellow}%{\e[J%}'"$PROMPT"
 
However if you run something like "man" that applies it own boldface or
underlining to the text, you'll see the default colors get restored in
the middle of the output.  This happens in bash too.  You will be much
better off changing the terminal's idea of the defaults.

Re: ANSI bg colour outside of prompt area

[junkcommander0]

Thanks so much Guys!

I completely understand, changing the terminal background doesn't look 
like it's something that is supposed to be able to be done. 

} PROMPT=$'%K{yellow}%{\e[J%}'"$PROMPT"
Thank you very much, This works!! 

Unfortunately, within tmux it only colours the prompt. Outside of it 
though it works beautifully. I have a feeling you're right though, if 
I'm going to get this to work reliably I'll have to see if I can 
sandwich a little function into st's source for changing the value of 
the background colour.

It's a little out of my league for now, but it's something to look 
forward to as I learn a little more :).


Just in case you're curious, I do have custom colours set up in my 
terminal, but I used to use this to quickly switch the terminal 
background colour to white if I was in a dark room and someone flicked a 
light on. It's kind of petty, but it was a nifty little trick that made 
it easier to see the screen when there was a glare on it.

As a workaround for now I have a little alias that switches the value of 
the background colour in st's config.h, and recompiles it. It's not 
quite the same as toggling it in the terminal I'm working in, but it's 
not terribly difficult to open a new terminal with a different 
background colour.


A great week/weekend to all of you,

Will

On Sun, Feb 22, 2015 at 11:10:07AM -0800, Bart Schaefer wrote:
>On Feb 22,  8:23am, junkcommander0@gmail.com wrote:
>}
>} I was wondering if anyone has had any success setting BG colours in
>} their terminal with ANSI escape sequences or with some other method.
>
>If you're using a graphical desktop with terminal emulators for shell
>windows, you'd typically want to do this via the emulator configuration
>instead of by sending ANSI sequences.  E.g.
>
>    xterm -fg yellow -bg black
>
>This gives you a lot more variety of possible colors to chose from; you
>can use the entire graphical color palette rather than being limited to
>what the emulator defines as e.g. "bold + yellow" for ANSI.
>
>However ...
>
>} I had some aliases with escape sequences that I used for bash and shell
>} that would change the background colour. The colour was never reset, and
>} clearing the screen would change the entire terminal's background
>} colour.
>[...]
>} 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.
>
>Also ZLE emits a "clear to end of screen" before printing the prompt to
>remove anything that another program might have left behind.  This is
>to keep your prompt from getting obscured by overstriking something.
>However, combined with the color reset, that has the effect of restoring
>the default background color for everything below the prompt position.
>
>So the trick is to emit the clear-screen again after changing the color
>in the prompt.
>
>    PROMPT=$'%K{yellow}%{\e[J%}'"$PROMPT"
>
>However if you run something like "man" that applies it own boldface or
>underlining to the text, you'll see the default colors get restored in
>the middle of the output.  This happens in bash too.  You will be much
>better off changing the terminal's idea of the defaults.

Re: ANSI bg colour outside of prompt area

[ZyX]

22.02.2015, 22:12, "Bart Schaefer" <schaefer@brasslantern.com>:
> On Feb 22,  8:23am, junkcommander0@gmail.com wrote:
> }
> } I was wondering if anyone has had any success setting BG colours in
> } their terminal with ANSI escape sequences or with some other method.
>
> If you're using a graphical desktop with terminal emulators for shell
> windows, you'd typically want to do this via the emulator configuration
> instead of by sending ANSI sequences.  E.g.
>
>     xterm -fg yellow -bg black
>
> This gives you a lot more variety of possible colors to chose from; you
> can use the entire graphical color palette rather than being limited to
> what the emulator defines as e.g. "bold + yellow" for ANSI.

Most of time you can use just the same 24-bit palette when setting color via command-line arguments, .Xresources and escape sequences, except that not when you use the strange method OP uses.

*Currently* you can as well use 24-bit palette for highlighting *everything*: via

    \e[{fg|bg};2;{Red};{Green};{Blue}m

(where fg is 38, bg is 48, Red, Green and Blue are decimal numbers 0..255). Colors set this way are treated (including clearing and replacing with another color) just like any other color from 4- or 8-bit palette.

This is supported by konsole (it is the oldest terminal supporting this), st, vte, iTerm2 (Mac OS X), ConEmu (Windows). This functionality was added to terminals after some time I created patch for Vim to use 24-bit colors (not merged) and also added this to powerline (first patch was sent to mailing list brought this capability to the public attention, powerline was a follow-up and less useful due to the lack of releases on that stage and hence announcements).

ConEmu was a great example of how proper internal implementation makes such changes easy: it took only 38 minutes to add support for 24-bit color from the time I pointed out where these sequences are described to the ConEmu author (2.5 hours from the time I pointed out that such a thing exists) (http://habrahabr.ru/post/164687/#comment_5671059, Russian text only). On the other side, xterm was first to add support for these escape sequences and *still* does not have support for true color (it simply takes closes (in RGB space) color from its 8-bit palette when it sees such sequences).

> However ...
>
> } I had some aliases with escape sequences that I used for bash and shell
> } that would change the background colour. The colour was never reset, and
> } clearing the screen would change the entire terminal's background
> } colour.
> [...]
> } 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.

I am wondering whether same thing may apply to \C-n (0x0E, Shift Out). It is the second annoying thing that may garble everything, much more annoying since it changes the view of most characters and I have to type either `echo $'\ec'` or `echo $'\c-o'`.

I mean, whether it makes sense to output \C-o to drop SO mode by default just like it is done currently with colors.

>
> Also ZLE emits a "clear to end of screen" before printing the prompt to
> remove anything that another program might have left behind.  This is
> to keep your prompt from getting obscured by overstriking something.
> However, combined with the color reset, that has the effect of restoring
> the default background color for everything below the prompt position.
>
> So the trick is to emit the clear-screen again after changing the color
> in the prompt.
>
>     PROMPT=$'%K{yellow}%{\e[J%}'"$PROMPT"
>
> However if you run something like "man" that applies it own boldface or
> underlining to the text, you'll see the default colors get restored in
> the middle of the output.  This happens in bash too.  You will be much
> better off changing the terminal's idea of the defaults.

Re: ANSI bg colour outside of prompt area

[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.

Re: ANSI bg colour outside of prompt area

[ZyX]

23.02.2015, 02:43, "Ray Andrews" <rayandrews@eastlink.ca>:
> 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.

Re: ANSI bg colour outside of prompt area

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Sun, Feb 22, 2015 at 4:10 PM, ZyX <kp-pav@yandex.ru> wrote:
>
> 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.”
>

Those were pretty much my thoughts as well. I have never once in the 30+
years I've been programming wanted to change the default background color
of an existing terminal session on the fly; i.e., outside of a particular
app. This is something you spend a few minutes every five years or so
deciding on your personal preference then set once and forget about it. If
you like different background colors to signify a particular purpose for a
given terminal you, again, figure out what those should be then create an
easy mechanism for invoking a terminal with the desired characteristics (be
it background color, width, height, or anything else).


> Thus I would say that implementing such option is a pure waste of time.
>

Agreed. Please do not implement this. There are already way too many zsh
options with very limited utility but which cause much confusion.


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/22/2015 04:10 PM, ZyX wrote:
> Thus I would say that implementing such option is a pure waste of time. 

Sure, I expect most will agree with you.  But it would be compatible 
with bash, and I still think more 'correct', since it is more in keeping 
with ANSI.  I'm also guessing that it would be very easy to do, since 
probably the ZLE code that clears the screen is one line, or very few, 
anyway.  Also, the more I think about it the more I'm sure I'd like the 
'bash_color' option for some of my own functions. It certainly is not 
important however.

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 22,  4:28pm, Kurtis Rader wrote:
}
} Those were pretty much my thoughts as well. I have never once in the 30+
} years I've been programming wanted to change the default background color
} of an existing terminal session on the fly; i.e., outside of a particular
} app. This is something you spend a few minutes every five years or so
} deciding on your personal preference then set once and forget about it.

Many terminal emulators (more modern than xterm; e.g. gnome-terminal and
PuTTY, among others) provide GUI menus for doing this sort of thing.  In
gnome-terminal it's Terminal -> Change Profile, you can set up as many
different profiles as you like with different font/color/lines/columns
etc. combinations, and switch among them as necessary.

Of course "st" is designed to be extremely simple/lightweight, so it does
not have that sort of feature available.

The only other argument that the shell should get involved in this is
for non-GUI consoles.  I've seen reference to default console colors
having to be compiled in to the kernel, which does seem like overkill.
Even so, as Zyx pointed out, there's no way for the shell to make color
changes stick when other programs run.

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 23, 12:55am, ZyX wrote:
} Subject: Re: ANSI bg colour outside of prompt area
}
} > 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.
} 
} I am wondering whether same thing may apply to \C-n (0x0E, Shift Out).
} It is the second annoying thing that may garble everything, much more
} annoying since it changes the view of most characters and I have to
} type either `echo $'\ec'` or `echo $'\c-o'`.
}
} I mean, whether it makes sense to output \C-o to drop SO mode by
} default just like it is done currently with colors.

Hrm.  The Lock Shift feature to chose character sets is a lot less common,
the prompt code would actually have to check that the G0 capability is
present in the terminal definition, etc.  I'm not personally familiar with
the terminal handling code in prompt.c ... on brief examiniation I can't
even find where it's emitting color reset and clear-screen.

Still, there's no reason you can't put $'%{\CO%}' at the front of $PS1.
Or putting that in $PROMPT_EOL_MARK might work as well.

Re: ANSI bg colour outside of prompt area

[Vincent Lefevre]

On 2015-02-23 03:10:17 +0300, ZyX wrote:
> 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.

Similar with GNU ls: echo $'\e[41m'; ls --color

The red background stops as soon as ls needs to use the normal color.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ANSI bg colour outside of prompt area

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Sun, Feb 22, 2015 at 5:14 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> Many terminal emulators (more modern than xterm; e.g. gnome-terminal and
> PuTTY, among others) provide GUI menus for doing this sort of thing.  In
> gnome-terminal it's Terminal -> Change Profile, you can set up as many
> different profiles as you like with different font/color/lines/columns
> etc. combinations, and switch among them as necessary.
>
> Of course "st" is designed to be extremely simple/lightweight, so it does
> not have that sort of feature available.
>

Don't try to teach grandma how to suck eggs :-)

My first programming course in 1976 involved the use of a teletype model-33
with paper tape punch/reader: http://en.wikipedia.org/wiki/Teletype_Model_33.
My second course to learn FORTRAN required going to the school district
administrative offices to use their IBM 80-column card punch machine then
taking the card deck to another building to be submitted for running
overnight: http://en.wikipedia.org/wiki/Punched_card.

Kids these days just don't understand how walking to school and back home
uphill both ways through two meters of snow helps build character :-)

The only other argument that the shell should get involved in this is
> for non-GUI consoles.  I've seen reference to default console colors
> having to be compiled in to the kernel, which does seem like overkill.
> Even so, as Zyx pointed out, there's no way for the shell to make color
> changes stick when other programs run.
>

I have several Linux virtual-machines and, yes, the emulated serial console
has a hard-coded black background. Boo-hoo. Honestly, if you're spending
more than a few minutes a year interacting with a system via such an
interface you still have options that are preferable to bolting on another
"feature" to zsh that only 0.001% of its users will find valuable.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: ANSI bg colour outside of prompt area

[Vincent Lefevre]

On 2015-02-22 17:14:18 -0800, Bart Schaefer wrote:
> Many terminal emulators (more modern than xterm; e.g. gnome-terminal and
> PuTTY, among others) provide GUI menus for doing this sort of thing.  In
> gnome-terminal it's Terminal -> Change Profile, you can set up as many
> different profiles as you like with different font/color/lines/columns
> etc. combinations, and switch among them as necessary.
> 
> Of course "st" is designed to be extremely simple/lightweight, so it does
> not have that sort of feature available.

There doesn't need to be a GUI. Implementing an option to choose the
background color should be very simple. Or a private escape sequence
to change the default background color (I've said "default background",
not the current background as changed by setab or setb).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ANSI bg colour outside of prompt area

[Vincent Lefevre]

On 2015-02-22 17:22:04 -0800, Bart Schaefer wrote:
> On Feb 23, 12:55am, ZyX wrote:
[...]
> } I mean, whether it makes sense to output \C-o to drop SO mode by
> } default just like it is done currently with colors.
> 
> Hrm.  The Lock Shift feature to chose character sets is a lot less common,
> the prompt code would actually have to check that the G0 capability is
> present in the terminal definition, etc.  I'm not personally familiar with
> the terminal handling code in prompt.c ... on brief examiniation I can't
> even find where it's emitting color reset and clear-screen.
> 
> Still, there's no reason you can't put $'%{\CO%}' at the front of $PS1.
> Or putting that in $PROMPT_EOL_MARK might work as well.

FYI, I do something like that in my precmd function:

    [[ -n $TTY && -n $terminfo ]] && {
        echoti rmacs
        echoti sgr0
        echoti cnorm
    } > $TTY 2> /dev/null

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ANSI bg colour outside of prompt area

[Vincent Lefevre]

On 2015-02-22 17:44:27 -0800, Kurtis Rader wrote:
> I have several Linux virtual-machines and, yes, the emulated serial
> console has a hard-coded black background. Boo-hoo.

Hard-coded? Not for the standard Linux console (a.k.a. VT 1-6).
The color can be changed with:

  setterm --background white --foreground black --store

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ANSI bg colour outside of prompt area

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

On Sun, Feb 22, 2015 at 6:04 PM, Vincent Lefevre <vincent@vinc17.net> wrote:

> On 2015-02-22 17:44:27 -0800, Kurtis Rader wrote:
> > I have several Linux virtual-machines and, yes, the emulated serial
> > console has a hard-coded black background. Boo-hoo.
>
> Hard-coded? Not for the standard Linux console (a.k.a. VT 1-6).
> The color can be changed with:
>
>   setterm --background white --foreground black --store


Sorry, poor choice of words on my part. I meant to say the default colors.
I've never bothered to look up how to alter the linux console background
color because I, and any sane person, uses it only for initial
bootstrapping and error recovery -- not on an ongoing basis. Which doesn't
change my point that just because people use zsh via mechanisms that don't
provide a convenient means of controlling the background color does not
mean we should add another option to zsh.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/22/2015 05:44 PM, Kurtis Rader wrote:
> Kids these days just don't understand how walking to school and back 
> home uphill both ways through two meters of snow helps build character 
> :-) 

I have walked to school uphill both ways through--ok, it was only two 
feet of snow, but it *was* uphill both ways.  God strike me.

... preferable to bolting on another "feature" to zsh that only 0.001% 
of its users will find valuable.
Well it ain't going to happen and that's nothing to cry about, still, 
I'd ask how hard would it be?  Could be a nice little come-on for 
bashers and I'm quite sure I'd use it, now that I think about it.  You 
don't miss something you've not had, but once you have it who's to say 
who might not like it?  I'm thinking how cool it might be to have 
different builds on different xterms showing different BG colors, so 
that it's easier to keep track of which is which.  But, yes, it is just 
a bon-bon.

Re: ANSI bg colour outside of prompt area

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

Ray, You're missing the point. Every feature has costs as well as benefits.
The costs are not limited to writing the original patch to the source code.
Every new feature makes future changes more difficult. Every new feature
requires additional verbiage to the documentation and thus a potential
source of confusion. Every new feature makes it more likely that someone
will be surprised by the behavior of the program. Every new feature
increases the cost of supporting the program. Etcetera.

The value of the proposed feature has to be considerably larger than those
costs. I love zsh. I also hate a lot of the "features" that have been added
which benefit a very tiny percentage of its users at the expense of
everyone else. Including the people trying to help new zsh users and keep
the project alive and the preferable choice from the alternatives. There
are a million features that could be added to zsh which would make someone
happy. Implementing all those features would kill zsh.

On Sun, Feb 22, 2015 at 7:41 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 02/22/2015 05:44 PM, Kurtis Rader wrote:
>
>> Kids these days just don't understand how walking to school and back home
>> uphill both ways through two meters of snow helps build character :-)
>>
>
> I have walked to school uphill both ways through--ok, it was only two feet
> of snow, but it *was* uphill both ways.  God strike me.
>
> ... preferable to bolting on another "feature" to zsh that only 0.001% of
> its users will find valuable.
> Well it ain't going to happen and that's nothing to cry about, still, I'd
> ask how hard would it be?  Could be a nice little come-on for bashers and
> I'm quite sure I'd use it, now that I think about it.  You don't miss
> something you've not had, but once you have it who's to say who might not
> like it?  I'm thinking how cool it might be to have different builds on
> different xterms showing different BG colors, so that it's easier to keep
> track of which is which.  But, yes, it is just a bon-bon.
>



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: ANSI bg colour outside of prompt area

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Sun, Feb 22, 2015 at 7:41 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> I have walked to school uphill both ways through--ok, it was only two feet
> of snow, but it *was* uphill both ways.


No, it could not have been uphill both ways. That's the point of the
aphorism "I walked uphill both ways". In our reality there could only be a
net increase in elevation in one direction. When someone claims to have
"walked uphill both ways" they are exaggerating, usually for ironic effect.
When you say "it *was* uphill both ways" you're implying it was literally
true. Which is impossible.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 22,  5:44pm, Kurtis Rader wrote:
}
} Don't try to teach grandma how to suck eggs :-)

Grandma ain't the only person reading this.

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/22/2015 08:03 PM, Kurtis Rader wrote:
> Ray, You're missing the point. Every feature has costs as well as benefits.
> The costs are not limited to writing the original patch to the source code.
> Every new feature makes future changes more difficult. Every new feature
> requires additional verbiage to the documentation and thus a potential
> source of confusion. Every new feature makes it more likely that someone
> will be surprised by the behavior of the program. Every new feature
> increases the cost of supporting the program. Etcetera.

I couldn't agree more.  There is always a 'price'--several prices, some 
of them up-front and obvious, but always some lurking in the dark 
waiting to ambush you.
>
> The value of the proposed feature has to be considerably larger than those
> costs.

Of course.  I argue for it, but the devs will decide if the 'price' is 
worth the minimal utility.  I'd suspect that the price would be very 
low, but it's not my call.  I mostly like it as a bash compatibility 
thing--maybe this is important to bashers, who knows. One for sure.  
It's not worth any trouble.
> I love zsh. I also hate a lot of the "features" that have been added
> which benefit a very tiny percentage of its users at the expense of
> everyone else. Including the people trying to help new zsh users and keep
> the project alive and the preferable choice from the alternatives. There
> are a million features that could be added to zsh which would make someone
> happy. Implementing all those features would kill zsh.

Again, I couldn't agree more.  We see Bart and Peter and others 
wrestling with this kind of stuff every day, it's an intractable mess.  
Nope, even if it were my call, I'd only do this BG color thing if it 
were dead simple, absolutely clear and predictable and reliable, and of 
real worth to bashers.

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 22,  8:14pm, Kurtis Rader wrote:
}
} No, it could not have been uphill both ways.

Are we really having this discussion?

Re: ANSI bg colour outside of prompt area

[Vincent Lefevre]

On 2015-02-22 19:41:08 -0800, Ray Andrews wrote:
> I'm thinking how cool it might be to have different builds on
> different xterms showing different BG colors, so that it's easier to
> keep track of which is which. But, yes, it is just a bon-bon.

You shouldn't mix up the default background/foreground color pair and
the current background/foreground color pair. The user completely
controls the former one. The latter one can be chosen by programs
that output text (this includes the shell), each time they need to do
some output. With xterm, you can set the default background/foreground
colors with the -bg and -fg options (or via X resources); it is possible
to change these default colors dynamically via the "dynamic color"
feature (when enabled).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ANSI bg colour outside of prompt area

[ZyX]

23.02.2015, 04:23, "Bart Schaefer" <schaefer@brasslantern.com>:
> On Feb 23, 12:55am, ZyX wrote:
> } Subject: Re: ANSI bg colour outside of prompt area
> }
> } > 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.
> }
> } I am wondering whether same thing may apply to \C-n (0x0E, Shift Out).
> } It is the second annoying thing that may garble everything, much more
> } annoying since it changes the view of most characters and I have to
> } type either `echo $'\ec'` or `echo $'\c-o'`.
> }
> } I mean, whether it makes sense to output \C-o to drop SO mode by
> } default just like it is done currently with colors.
>
> Hrm.  The Lock Shift feature to chose character sets is a lot less common,
> the prompt code would actually have to check that the G0 capability is
> present in the terminal definition, etc.  I'm not personally familiar with
> the terminal handling code in prompt.c ... on brief examiniation I can't
> even find where it's emitting color reset and clear-screen.
>
> Still, there's no reason you can't put $'%{\CO%}' at the front of $PS1.
> Or putting that in $PROMPT_EOL_MARK might work as well.

I have actually put this into `precmd_functions` array. And am experiencing weird behavior since the time I put it: character set is not changing on SO ever since I started to emit \C-o in konsole.

I mean, I start a new terminal using konsole -e zsh -f and it does not change character set on `echo $'\C-n'`. Need to change to fbterm (framebuffer terminal) to see the switch; this one is not going to lock on \C-o mode.

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 23, 10:46am, Vincent Lefevre wrote:
} Subject: Re: ANSI bg colour outside of prompt area
}
} On 2015-02-22 19:41:08 -0800, Ray Andrews wrote:
} > I'm thinking how cool it might be to have different builds on
} > different xterms showing different BG colors, so that it's easier to
} > keep track of which is which. But, yes, it is just a bon-bon.
} 
} You shouldn't mix up the default background/foreground color pair and
} the current background/foreground color pair.

For what it's worth, the way I deal with keeping track of builds and
hosts is to include the host name and part of the version string in
the prompt, and color each of those differently.  The background and
foreground stay the same because I have them adjusted for maximum
readability.

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/23/2015 08:36 AM, Bart Schaefer wrote:
> For what it's worth, the way I deal with keeping track of builds and
> hosts is to include the host name and part of the version string in
> the prompt, and color each of those differently.  The background and
> foreground stay the same because I have them adjusted for maximum
> readability.
>
I have this in preexec():

echo $ZSH_PATCHLEVEL

BTW, there seems to be a bit of fuzz in the term 'background' color.  
Sometimes it seems to mean just the color behind any typed text, other 
times it refers to the background of the whole screen. Are there more 
unambiguous terms?

Re: ANSI bg colour outside of prompt area

[Bart Schaefer]

On Feb 23,  8:51am, Ray Andrews wrote:
}
} BTW, there seems to be a bit of fuzz in the term 'background' color.  
} Sometimes it seems to mean just the color behind any typed text, other 
} times it refers to the background of the whole screen. Are there more 
} unambiguous terms?

As far as I know it always refes to the background of some text, but text
includes "invisible" things like tabs and spaces, and clearing the screen
writes spaces to every possible character location.

Put another way, I expect that most terminal emulators treat the whole
screen as a grid of character positions and color it by assigning to the
background of every cell.  There is no other background.

Re: ANSI bg colour outside of prompt area

[junkcommander0]

I'm still pretty green when it comes to all of this, but I'm not sure if 
anyone would be too disoriented by this not working in zsh like it did 
in bash.

I'm actually not entirely sure where I originally came across it to 
begin with, I found a little perl script that ran in urxvt and changed 
background colours, and then I started reading up on ANSI escape 
sequences to see what it was really doing. I can understand not wanting 
to unecessarily complicate things too much, fresh out of the 450pg zsh 
manual haha :).

Sorry for all of the fuss, I'm just poking around and trying to 
understand how things work.

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/23/2015 06:53 PM, Bart Schaefer wrote:
> On Feb 23,  8:51am, Ray Andrews wrote:
> }
> } BTW, there seems to be a bit of fuzz in the term 'background' color.
> } Sometimes it seems to mean just the color behind any typed text, other
> } times it refers to the background of the whole screen. Are there more
> } unambiguous terms?
>
> As far as I know it always refes to the background of some text, but text
> includes "invisible" things like tabs and spaces, and clearing the screen
> writes spaces to every possible character location.

That would be the answer right there.
>
> Put another way, I expect that most terminal emulators treat the whole
> screen as a grid of character positions and color it by assigning to the
> background of every cell.  There is no other background.
Thanks, it's sorta obvious now that I see it--clearing the screen 
doesn't create 'nothing' it creates a screen of spaces.

Re: ANSI bg colour outside of prompt area

[Ray Andrews]

On 02/23/2015 07:49 PM, junkcommander0@gmail.com wrote:
> I'm still pretty green when it comes to all of this, but I'm not sure 
> if anyone would be too disoriented by this not working in zsh like it 
> did in bash.
>
> I'm actually not entirely sure where I originally came across it to 
> begin with, I found a little perl script that ran in urxvt and changed 
> background colours, and then I started reading up on ANSI escape 
> sequences to see what it was really doing. I can understand not 
> wanting to unecessarily complicate things too much, fresh out of the 
> 450pg zsh manual haha :).
>
> Sorry for all of the fuss, I'm just poking around and trying to 
> understand how things work.
>
>
You'll find the devs here *never* leave you hanging.  FWIW I took a 
heroic stab at the code, thinking I might find some simple function to 
comment out, or something, that would produce the bash behavior, but I 
couldn't find the right leverto pull.

Re: ANSI bg colour outside of prompt area

[Vincent Lefevre]

On 2015-02-23 08:36:37 -0800, Bart Schaefer wrote:
> For what it's worth, the way I deal with keeping track of builds and
> hosts is to include the host name and part of the version string in
> the prompt, and color each of those differently.

I put the hostname in the prompt and the window title.

> The background and foreground stay the same because I have them
> adjusted for maximum readability.

Ditto. And many applications produce colored output. If the background
changed, some colors would necessarily be unreadable.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)