Foreground/background color logic?

[lengstrom]

Hi,

I'm having some troubles getting the colors in my pyte screen to match those in my true tty.

For example, running vim in my tty (sorry if I'm abusing vocabulary), we have:

Then in pyte, I get this (visualizing using the urwid library):

At the character directly right to the cursor position in the pyte Screen, {"x": 8, "y":0), I get the following _char instance:

(pdb) buff[0][9]
_Char(data=u'r', fg=u'default', bg=u'default', bold=False, italics=False, underscore=False, strikethrough=False, reverse=False)

Which is clearly not describing the same character right of the cursor in the Vim instance (which should have at least a red foreground color). What am I doing wrong here? Do I have to enable colors, or set certain environmental variables or flags in my pyte screen pty?

[superbobry]

The exact meaning of 'default' background is unspecified by ECMA-48 (see 49 here). So different terminals might implement it differently.

I think iTerm simply substitutes 'default' for the background colour from its color theme, while your implementation treats it as white.

[lengstrom]

Thanks for the response, that makes sense! Do you have any recommendations for handling this in practice?

[superbobry]

I've never written a themed terminal emulator, so unfortunately I can't give any practical advice here. Maybe @jonathanslenders has something to say?

[jonathanslenders]

Hi @lengstrom, I'm not sure what the issue is in this particular case.

What is your $TERM environment variable? Does Vim think it can use 256 colors? There are several independent ways of specifying the color. (ANSI, 256 or True color). Maybe Vi is mixing them in the current set-up. Not sure whether Pyte parses 256 colors as well, in pymux, I have patched some parts of the functionality in order to support more functionality.

Anyway, keep in mind that if you use Urwid to render the output, it won't necassarily reflect the same colors unless Urwid supports both ANSI and 256 color.

Jonathan

[superbobry]

Not sure whether Pyte parses 256 colors as well [...]

At the moment it doesn't, but I'd welcome a patch :)

[lengstrom]

@jonathanslenders $TERM == "xterm" in my pty (and in my tty). I'm actually using the BetterStream and BetterScreen classes in my project already :) - I've looked at pymux (along with prompt-toolkit and wuub/SublimePTY) a lot for my work. What are the methods of specifying the color to 256?

Urwid does support ANSI and 256.

Update: Looking at pymux's example, I set $TERM to xterm-256color, and I'm still receiving colors in 16 color format.

[superbobry]

Possibly a silly question, but do you export TERM=xterm-256color or do you just set it as TERM=...?

[superbobry]

I think the issue might be caused by the fact that pyte does not handle colour palettes. Here's an excerpt from man console_codes:

ESC ]     OSC      (Should be: Operating system command) ESC ] P
                   nrrggbb: set palette, with parameter given in 7
                   hexadecimal digits after the final P :-(.  Here n
                   is the color (0-15), and rrggbb indicates the
                   red/green/blue values (0-255).  ESC ] R: reset
                   palette

I've added basic OSC processing in the master version, but palette handling is still not implemented (however, it shouldn't be very hard).