This is actually a problem that also goes on with screen. Here is what it looks like (in mutt):

mutt with browser visible behind http://s15.postimg.org/l4pupb7mx/muttmux.png

When running a terminal application that builds an updated interface from Guake, tmux and screen don't seem to display the default background colors that the displayed text have. (The effect is more subtle with, say, tilda, but the general idea is the same.)

This is a real killer for its usability/readability.

I messed around with the $TERM var as per this site's advice, but it didn't have any effect.

How can I force Guake to display the background provided by text interfaces like mutt?

other info

Strangely, this doesn't occur with dvtm, another multiplexer. I'm totally unfamiliar with it, though.


The question (and suggested answer) are a little obscure, but what is being described is mutt's use of the default color feature of ncurses (or slang). If your mutt color scheme uses the word "default" for the foreground or background, then at runtime mutt will ask ncurses/slang to use the terminal's default color.

Whether in an application such as mutt or in a multiplexer such as screen, it is implemented by SGR 39 (foreground default color, ^[[39m) and SGR 49 (background default color, ^[[49m). The multiplexer will use the terminal's actual SGR 39/49 support if it exists.

Applications such as the compositor can (relatively) easily detect the default foreground and background colors assigned to the terminal window and manipulate the background color to simulate a transparent window. Not everyone likes the effect (and because it detracts from readability, has not been implemented in xterm).

Default colors have their uses separate from transparent terminals, and mutt was one of the first applications where the feature was used (the result of a collaboration with Liviu Daia). It is coupled with the terminfo bce (back color erase) feature, which was originally not supported by GNU screen. That's been supported since 2002 (from the question it's unclear whether OP knew how to configure it).

If you want the background to be opaque, then

  • configure mutt without using the default color.
  • configure screen without enabling its bce support.

Further reading:

| improve this answer | |

I don't think you can achieve that in the terminal multiplexer and probably neither in the terminal emulator - it's the application that sets its colours not the terminal.

The reason why compositor makes the background translucent is the difference between how the escape sequences ^[[0m and ^[[40m are interpreted. The first (and default one) is interpreted as transparent (no opacity) while the other one is (full opacity) black. That you you usually see both as black is given by the fact that the terminal is blending it all against black background. Enters a compositing window manager and suddenly the transparent layer becomes really transparent and black stays black (with reduced opacity).

That said, you can try to convince mutt to use black for background so that it adds ^[[40m everytime there would effectively be ^[[0m (or ^[[49m]). Or you can have a look, whether your terminal emulator allows overriding the default background colour.

Another option is obviously disabling transparency or even compositing completely, which actually doesn't have to be the worst choice either.

| improve this answer | |
  • The strange thing about it is, it works just fine in the terminal emulator without a multiplexer. The dark gray background is applied to both text and blank characters consistently. Are the multiplexers trying to save bandwidth by only rendering printable characters or something? – bright-star Oct 3 '14 at 10:31
  • 1
    That's interesting. I can only guess, that there is some communication problem between the terminal multiplexer and terminal emulator it is running in. I would incline to blame the emulator rather than muxer, but that's just a gut feeling. It can as well be the muxer interpreting ^[[40m incorrectly as ^[[49m. The ultimate answer is in the code. :) – peterph Oct 3 '14 at 10:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.