GNOME Bugzilla – Bug 151260
support 'OSC Ps ; ?' to report back colours and font
Last modified: 2018-02-17 10:26:30 UTC
Apps like VIM use the XTERM_BACKGROUND variable to set the default colorscheme to something readable, which is currently why many are experiencing problems reading the default colorscheme on VIM which is set for a light background. For a full description of this issue, please see http://bugs.gentoo.org/show_bug.cgi?id=56290
Hmm. That upstream bug didn't look totally conclusive...
You can verify the bug yourself. If its not gnome-terminal, then you can point the finger somewhere else.
Can you give a short and consise description on how to reproduce this bug? Thanks.
First open up gnome-terminal and set your profile so that you have a dark black background. Now inside of the terminal, open up vim with a text file. Take note of the badly contrasted color vim is using. Then inside of vim :set bg=dark , and now notice how VIM is using a much better contract of colors. I was told that vim reads in the environmental variable XTERM_BACKGROUND.
The only thing I find strange is that doing 'set bg=dark' when I have a white background gives the same effect?
Nothing strange about that. Vim has no knowledge of what the background color of your terminal is, and it is because gnome-terminal isn't passing it. That's why I filed this bug.
This XTERM_BACKGROUND/FOREGROUND thing is not in xterm-196, which is the current one, afaict from grepping its source. Does any term use it? Is it spec'ed anywhere? Something of this kind might make sense, I guess.
Yeah the XTERM_{BACK,FORE}GROUND is a gentoo specific patch. As Mariano says, I think something like this might make sense, but it has to be a widespread used mechanism, or should be accepted/discussed upstream first.
This doesn't make sense because: 1. The background can change dynamically, in which case the environment variable will be incorrect. 2. The environment variable won't be available over ssh. The better solution would be to implement the control sequence used by "xtermcontrol --get-bg". Then vim could query gnome-terminal for the current background color.
That would make sense. Over to vte for that!
But I guess we already implement palette query control seqs?
(In reply to comment #11) > But I guess we already implement palette query control seqs? I don't know. xtermcontrol --get-bg hangs, must be pkilled in another terminal. It works on xterm and rxvt.
Where can I get this xtermcontrol thing? It's not included in xterm-267.
(In reply to comment #13) > Where can I get this xtermcontrol thing? It's not included in xterm-267. http://tinyurl.com/5rjumqv :-)
From xterm/ctlseqs.txt: """ Operating System Controls OSC Ps ; Pt ST OSC Ps ; Pt BEL Set Text Parameters. For colors and font, if Pt is a "?", the control sequence elicits a response which consists of the con- trol sequence which would set the corresponding value. """ So this would be 'OSC 11 ; ?' . AFAICT we can support this safely; it does not have the security issue that reporting back window title etc. has.
I can see the point in querying fg/bg colors, and I'm working on it. There's a patch in bug 567444. Other sibling issues: bug 640040, bug 722446. What would be the point in setting/querying the font? Sounds useless to me.
Being able to both *set and query* font (an essentially arbitraty string) would be a CVE-2003-0070 style vulnerability, I think. (See commit 8b971a7b2c59902914ecbbc3915c45dd21530a91.) We can pseudo-support these sequences, but setting should just be ignored and query should just report a fixed string, IMHO.
Well, I think the current approach (setting is ignored, query is ignored too) is just as good :)
"OSC P ; ?" does report the colour back, so I think this one has been fixed in the meantime. OSC 50 will not be supported.