Re: ANSI bg colour outside of prompt area

[ZyX <kp-pav@xxxxxxxxx>]

22.02.2015, 22:12, "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>:
> On Feb 22,  8:23am, junkcommander0@xxxxxxxxx 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.