GNU bug report logs -
#29473
25.3; 'background-mode is 'light on console with black background
Previous Next
Reported by: Tim Landscheidt <tim <at> tim-landscheidt.de>
Date: Mon, 27 Nov 2017 14:54:02 UTC
Severity: minor
Tags: moreinfo
Found in version 25.3
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29473 in the body.
You can then email your comments to 29473 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29473
; Package
emacs
.
(Mon, 27 Nov 2017 14:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tim Landscheidt <tim <at> tim-landscheidt.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 27 Nov 2017 14:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In newsticker tree view on a Linux console with black back-
ground (both KDE's konsole application and "native" console
(Alt-Ctrl-F2), all under Fedora), titles of folders with no
items are displayed black on black, i. e. they are still
copyable, but not visible. Changing the selected title with
RET highlights that one correctly and hides the previous one
if it has 0 items, suggesting that the face
newsticker-treeview-face is at fault.
Changing (:foreground "black") to (:foreground "yellow") in
newsticker-treeview-face's (background light) case makes the
titles visible and indeed
(frame-parameter nil 'background-mode) returns 'light. This
also happens with Emacs' current master branch.
After glancing at the manual, I'm unclear whether:
1. Emacs should set 'background-mode correctly by itself
(and thus there is an error in the detection mechanism),
2. it is my duty to explicitly set background-mode (via
initial-frame-alist?) when using Emacs on a console, or
3. newsticker should use a different technique (I've used
Emacs on consoles many times and do not remember running
into similar problems with other parts of Emacs).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29473
; Package
emacs
.
(Sat, 02 Dec 2017 15:26:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 29473 <at> debbugs.gnu.org (full text, mbox):
Tim Landscheidt <tim <at> tim-landscheidt.de> writes:
> In newsticker tree view on a Linux console with black back-
> ground (both KDE's konsole application and "native" console
> (Alt-Ctrl-F2), all under Fedora),
> (frame-parameter nil 'background-mode) returns 'light. This
> also happens with Emacs' current master branch.
>
> After glancing at the manual, I'm unclear whether:
>
> 1. Emacs should set 'background-mode correctly by itself
> (and thus there is an error in the detection mechanism),
>
> 2. it is my duty to explicitly set background-mode (via
> initial-frame-alist?) when using Emacs on a console, or
I'm pretty sure it's #1, the manual explains that background-mode nil
should use automatic detection, and it sounds like that detection is
going wrong.
I don't see anything in lisp/term/linux.el that sets the background mode
at all. What does running 'echo $TERM' in a shell give you?
Looking at lisp/term/konsole.el, it looks like it uses the xterm
functions for everything. Could you try stepping through/adding
'message' calls in terminal-init-xterm and see if/where it goes wrong?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29473
; Package
emacs
.
(Sat, 09 Dec 2017 05:36:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 29473 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
>> In newsticker tree view on a Linux console with black back-
>> ground (both KDE's konsole application and "native" console
>> (Alt-Ctrl-F2), all under Fedora),
>> (frame-parameter nil 'background-mode) returns 'light. This
>> also happens with Emacs' current master branch.
>> After glancing at the manual, I'm unclear whether:
>> 1. Emacs should set 'background-mode correctly by itself
>> (and thus there is an error in the detection mechanism),
>> 2. it is my duty to explicitly set background-mode (via
>> initial-frame-alist?) when using Emacs on a console, or
> I'm pretty sure it's #1, the manual explains that background-mode nil
> should use automatic detection, and it sounds like that detection is
> going wrong.
> I don't see anything in lisp/term/linux.el that sets the background mode
> at all. What does running 'echo $TERM' in a shell give you?
> Looking at lisp/term/konsole.el, it looks like it uses the xterm
> functions for everything. Could you try stepping through/adding
> 'message' calls in terminal-init-xterm and see if/where it goes wrong?
(For the moment, I retract my claim that this also happens
on a "native" (Alt-Ctrl-F2) console because I can no longer
reproduce it and cannot remember my test setup, so the fol-
lowing is limited to konsole in Fedora 25.)
In konsole, $TERM is set to "xterm-256color":
| [tim <at> passepartout ~/src/emacs]$ echo $TERM
| xterm-256color
| [tim <at> passepartout ~/src/emacs]$
With interspersed message calls, I could find out that kon-
sole's response to the "Secondary Device Attributes (DA)"
query in terminal-init-xterm ("\e[>0c") is "^[[>0;115;0c":
| [tim <at> passepartout ~/src/emacs]$ perl -we 'print "\e[>0c";'; sleep 1; echo
| ^[[>0;115;0c
| [tim <at> passepartout ~/src/emacs]$
This version number (115) falls short of the test
"(>= version 242)" which would cause the background colour
to be queried, and rightly so, because konsole does not re-
spond to the query "\e]11;?\e\\":
| [tim <at> passepartout ~/src/emacs]$ perl -we 'print "\e]11;?\e\\";'; sleep 1; echo
| [tim <at> passepartout ~/src/emacs]$
(Sidenote: gnome-terminal reports back "^[[>1;4603;0c" and
"^[]11;rgb:2323/2727/2929^[\" but the latter is never que-
ried due to NUMBER1 being 1 and NUMBER2 being greater than
2000, so background-mode stills end up as 'light with gnome-
terminal.)
So then I tried to track down where background-mode's 'light
is actually coming from, and it seems to originate in
frame-set-background-mode's:
| (default-bg-mode
| (if (or (window-system frame)
| (and tty-type
| (string-match "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)"
| tty-type)))
| 'light
| 'dark))
with tty-type being "xterm-256color". This logic was first
introduced in:
| commit 5ebc02b3656890d1d110c671129c64547bdbcdd6
| Author: Eli Zaretskii <eliz <at> gnu.org>
| Date: Sat Oct 28 18:48:08 2000 +0000
| (normal-top-level): If the value of $TERM indicates that
| we are running from xterm or one of its work-alikes, default to a
| light background mode.
Curious, I installed xterm and indeed it has black fore-
ground on white background which I had not only forgotten
about, but also for example Wikipedia uses a black back-
ground xterm to illustrate its article
(https://en.wikipedia.org/wiki/Xterm). D'oh.
My assumption now is that Emacs's detection mechanism cannot
be "fixed" for konsole in Fedora 25 and I should manually
set frame-background-mode to 'dark.
But: In Fedora 26, konsole 17.04.1 (in contrast to Fedora
25's konsole 16.12.3) still returns "^[[>0;115;0c" as
version number, /but/ "\^[]11;rgb:0000/0000/0000^G" for the
background colour.
So one possible improvement could be to query the background
colour either unconditionally or also on "(= version 115)".
This would increase the start-up time by (at most) two se-
conds (xterm-query-timeout) for terminals that do not sup-
port this query AFAIUI.
(So that I don't forget: I used:
| [tim <at> passepartout ~/src/emacs]$ make && ./src/emacs -Q -L $PWD -nw --eval '(switch-to-buffer "*Messages*")'
for testing.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29473
; Package
emacs
.
(Sat, 09 Dec 2017 14:06:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 29473 <at> debbugs.gnu.org (full text, mbox):
Tim Landscheidt <tim <at> tim-landscheidt.de> writes:
> With interspersed message calls, I could find out that kon-
> sole's response to the "Secondary Device Attributes (DA)"
> query in terminal-init-xterm ("\e[>0c") is "^[[>0;115;0c":
>
> | [tim <at> passepartout ~/src/emacs]$ perl -we 'print "\e[>0c";'; sleep 1; echo
> | ^[[>0;115;0c
> | [tim <at> passepartout ~/src/emacs]$
>
> This version number (115) falls short of the test
> "(>= version 242)" which would cause the background colour
> to be queried, and rightly so, because konsole does not re-
> spond to the query "\e]11;?\e\\":
>
> | [tim <at> passepartout ~/src/emacs]$ perl -we 'print "\e]11;?\e\\";'; sleep 1; echo
>
> | [tim <at> passepartout ~/src/emacs]$
> (Sidenote: gnome-terminal reports back "^[[>1;4603;0c" and
> "^[]11;rgb:2323/2727/2929^[\" but the latter is never que-
> ried due to NUMBER1 being 1 and NUMBER2 being greater than
> 2000, so background-mode stills end up as 'light with gnome-
> terminal.)
Ah, interesting. It seems the versions of gnome-terminal are rather
non-standard. Which version of gnome-terminal is this, and does it
support the other xterm calls?
;; If version is 216 (the version when modifyOtherKeys was
;; introduced) or higher, initialize the
;; modifyOtherKeys support.
(when (>= version 216)
(xterm--init-modify-other-keys))
;; In version 203 support for accessing the X selection was
;; added. Hterm reports itself as version 256 and supports it
;; as well. gnome-terminal doesn't and is excluded by this
;; test.
(when (>= version 203)
;; Most xterms seem to have it disabled by default, and if it's
;; disabled, C-y will incur a timeout, so we only use it if the user
;; explicitly requests it.
;;(xterm--init-activate-get-selection)
(xterm--init-activate-set-selection))))))
> So then I tried to track down where background-mode's 'light
> is actually coming from, and it seems to originate in
> frame-set-background-mode's:
>
> | (default-bg-mode
> | (if (or (window-system frame)
> | (and tty-type
> | (string-match "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)"
^^
Hmm, those backslashes are a bug, I think.
> | tty-type)))
> | 'light
> | 'dark))
>
> with tty-type being "xterm-256color".
> My assumption now is that Emacs's detection mechanism cannot
> be "fixed" for konsole in Fedora 25 and I should manually
> set frame-background-mode to 'dark.
Yes, looks like there is no way for Emacs to detect it.
> But: In Fedora 26, konsole 17.04.1 (in contrast to Fedora
> 25's konsole 16.12.3) still returns "^[[>0;115;0c" as
> version number, /but/ "\^[]11;rgb:0000/0000/0000^G" for the
> background colour.
Thanks for tracking all these details down!
> So one possible improvement could be to query the background
> colour either unconditionally or also on "(= version 115)".
> This would increase the start-up time by (at most) two se-
> conds (xterm-query-timeout) for terminals that do not sup-
> port this query AFAIUI.
Hmm, I think 2 seconds is too much. Is there no way to distinguish
between konsole versions? Perhaps file a bug against konsole to ask
them to bump the reported version?
Severity set to 'minor' from 'normal'
Request was from
Noam Postavsky <npostavs <at> users.sourceforge.net>
to
control <at> debbugs.gnu.org
.
(Fri, 15 Dec 2017 01:14:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29473
; Package
emacs
.
(Fri, 03 Sep 2021 06:45:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 29473 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> Ah, interesting. It seems the versions of gnome-terminal are rather
> non-standard. Which version of gnome-terminal is this, and does it
> support the other xterm calls?
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I can reproduce the problem on Emacs 27.1 (and older), but not in Emacs
28, so I think this problem (wrong background colour detection in Gnome
Terminal) is probably fixed now.
Is anybody else seeing problems in Emacs 28 with this combination (i.e.,
"emacs -nw" from the trunk and Gnome Terminal)?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 03 Sep 2021 06:45:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#29473
; Package
emacs
.
(Sun, 03 Oct 2021 09:45:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 29473 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I can reproduce the problem on Emacs 27.1 (and older), but not in Emacs
> 28, so I think this problem (wrong background colour detection in Gnome
> Terminal) is probably fixed now.
>
> Is anybody else seeing problems in Emacs 28 with this combination (i.e.,
> "emacs -nw" from the trunk and Gnome Terminal)?
More information was requested, but no response was given within a
month, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
29473 <at> debbugs.gnu.org and Tim Landscheidt <tim <at> tim-landscheidt.de>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 03 Oct 2021 09:45:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 31 Oct 2021 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 313 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.