GNU bug report logs -
#22343
25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22343 in the body.
You can then email your comments to 22343 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#22343
; Package
emacs
.
(Sun, 10 Jan 2016 21:21:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Clément Pit--Claudel <clement.pitclaudel <at> live.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 10 Jan 2016 21:21:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
This is a cute bug. Run the following two commands (in bash):
# Set Emacs.background in Xresources
$ xrdb <(echo "Emacs.background: #2e3436")
# Run Emacs with same background on default face
$ emacs -q --eval "(set-face-attribute 'default nil :background \"#2e3436\")"
On my machine, the two colors are not rendered the same. I've attached a screenshot. What essentially happens is that anywhere where text is drawn the background is indeed #2e3436, but on the rest of the frame it's #2d3335. Amusingly, these two colors have distinct RGB and HSL values, but their CMYK and HSB values are the same (or so says http://rgb.to/hex/2d3335 and http://rgb.to/hex/2e3436, at least).
The reason I came across this is that I use Emacs' tango-dark theme, which uses that background color. Since I didn't like Emacs popping up with a white background and immediately switching, I set the same background in my .Xresources.
To observe the bug more clearly, just take a screenshot and open it in your favourite image editor, then use the magic wand with a tolerance of 0 (see other screenshot). Or use the color picker.
What could cause this problem? A roundtripping issue with color conversions?
Clément.
In GNU Emacs 25.0.50.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
of 2016-01-08 built on clem-w50-mint
Repository revision: fb97523fa14e0fb7f0cebe92c749629ad0ab475e
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description: Linux Mint 17.2 Rafaela
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LC_TIME: en_DK.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase
cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 86528 3773)
(symbols 48 19882 0)
(miscs 40 42 85)
(strings 32 14576 5171)
(string-bytes 1 417874)
(vectors 16 11726)
(vector-slots 8 426886 4799)
(floats 8 164 77)
(intervals 56 191 0)
(buffers 976 11)
(heap 1024 39449 1144))
[inconsistent-background-color.png (image/png, attachment)]
[magic-wand.png (image/png, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Mon, 11 Jan 2016 18:57:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 22343 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> Date: Sun, 10 Jan 2016 16:19:50 -0500
>
> This is a cute bug. Run the following two commands (in bash):
>
> # Set Emacs.background in Xresources
> $ xrdb <(echo "Emacs.background: #2e3436")
> # Run Emacs with same background on default face
> $ emacs -q --eval "(set-face-attribute 'default nil :background \"#2e3436\")"
>
> On my machine, the two colors are not rendered the same. I've attached a screenshot. What essentially happens is that anywhere where text is drawn the background is indeed #2e3436, but on the rest of the frame it's #2d3335. Amusingly, these two colors have distinct RGB and HSL values, but their CMYK and HSB values are the same (or so says http://rgb.to/hex/2d3335 and http://rgb.to/hex/2e3436, at least).
>
> The reason I came across this is that I use Emacs' tango-dark theme, which uses that background color. Since I didn't like Emacs popping up with a white background and immediately switching, I set the same background in my .Xresources.
>
> To observe the bug more clearly, just take a screenshot and open it in your favourite image editor, then use the magic wand with a tolerance of 0 (see other screenshot). Or use the color picker.
>
> What could cause this problem? A roundtripping issue with color conversions?
Could this be the distant-background feature at work?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Mon, 11 Jan 2016 19:11:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 22343 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/11/2016 01:56 PM, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
>> Date: Sun, 10 Jan 2016 16:19:50 -0500
>>
>> This is a cute bug. Run the following two commands (in bash):
>>
>> # Set Emacs.background in Xresources
>> $ xrdb <(echo "Emacs.background: #2e3436")
>> # Run Emacs with same background on default face
>> $ emacs -q --eval "(set-face-attribute 'default nil :background \"#2e3436\")"
>>
>> On my machine, the two colors are not rendered the same. I've attached a screenshot. What essentially happens is that anywhere where text is drawn the background is indeed #2e3436, but on the rest of the frame it's #2d3335. Amusingly, these two colors have distinct RGB and HSL values, but their CMYK and HSB values are the same (or so says http://rgb.to/hex/2d3335 and http://rgb.to/hex/2e3436, at least).
>>
>> The reason I came across this is that I use Emacs' tango-dark theme, which uses that background color. Since I didn't like Emacs popping up with a white background and immediately switching, I set the same background in my .Xresources.
>>
>> To observe the bug more clearly, just take a screenshot and open it in your favourite image editor, then use the magic wand with a tolerance of 0 (see other screenshot). Or use the color picker.
>>
>> What could cause this problem? A roundtripping issue with color conversions?
>
> Could this be the distant-background feature at work?
I don't know :) How can I check? I was not aware of the distant-background feature; I'm only familiar with distant-foreground.
Clément.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Mon, 11 Jan 2016 19:15:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 22343 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22343 <at> debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> Date: Mon, 11 Jan 2016 14:09:53 -0500
>
> > Could this be the distant-background feature at work?
>
> I don't know :) How can I check? I was not aware of the distant-background feature; I'm only familiar with distant-foreground.
I think I meant distant-foreground...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Tue, 12 Jan 2016 02:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 22343 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/11/2016 02:14 PM, Eli Zaretskii wrote:
>> Cc: 22343 <at> debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
>> Date: Mon, 11 Jan 2016 14:09:53 -0500
>>
>>> Could this be the distant-background feature at work?
>>
>> I don't know :) How can I check? I was not aware of the distant-background feature; I'm only familiar with distant-foreground.
>
> I think I meant distant-foreground...
I see. Is distant-forground supposed to change the background color? What can I do to test this hypothesis?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Tue, 12 Jan 2016 16:47:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 22343 <at> debbugs.gnu.org (full text, mbox):
> Cc: 22343 <at> debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> Date: Mon, 11 Jan 2016 21:20:25 -0500
>
> On 01/11/2016 02:14 PM, Eli Zaretskii wrote:
> >> Cc: 22343 <at> debbugs.gnu.org
> >> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> >> Date: Mon, 11 Jan 2016 14:09:53 -0500
> >>
> >>> Could this be the distant-background feature at work?
> >>
> >> I don't know :) How can I check? I was not aware of the distant-background feature; I'm only familiar with distant-foreground.
> >
> > I think I meant distant-foreground...
>
> I see. Is distant-forground supposed to change the background color? What can I do to test this hypothesis?
No, I think I just got confused. Ignore me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Thu, 02 Dec 2021 09:04:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 22343 <at> debbugs.gnu.org (full text, mbox):
Clément Pit--Claudel <clement.pitclaudel <at> live.com> writes:
> This is a cute bug. Run the following two commands (in bash):
>
> # Set Emacs.background in Xresources
> $ xrdb <(echo "Emacs.background: #2e3436")
> # Run Emacs with same background on default face
> $ emacs -q --eval "(set-face-attribute 'default nil :background \"#2e3436\")"
>
> On my machine, the two colors are not rendered the same. I've attached
> a screenshot. What essentially happens is that anywhere where text is
> drawn the background is indeed #2e3436, but on the rest of the frame
> it's #2d3335.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I'm unable to reproduce this in Emacs 28 on Debian/bookworm. Are you
still seeing this issue in more recent versions of Emacs?
--
(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
.
(Thu, 02 Dec 2021 09:04:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Fri, 03 Dec 2021 04:30:03 GMT)
Full text and
rfc822 format available.
Message #28 received at 22343 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I cannot reproduce this issue any more.
On 12/2/21 4:03 AM, Lars Ingebrigtsen wrote:
> Clément Pit--Claudel <clement.pitclaudel <at> live.com> writes:
>
>> This is a cute bug. Run the following two commands (in bash):
>>
>> # Set Emacs.background in Xresources
>> $ xrdb <(echo "Emacs.background: #2e3436")
>> # Run Emacs with same background on default face
>> $ emacs -q --eval "(set-face-attribute 'default nil :background \"#2e3436\")"
>>
>> On my machine, the two colors are not rendered the same. I've attached
>> a screenshot. What essentially happens is that anywhere where text is
>> drawn the background is indeed #2e3436, but on the rest of the frame
>> it's #2d3335.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I'm unable to reproduce this in Emacs 28 on Debian/bookworm. Are you
> still seeing this issue in more recent versions of Emacs?
>
[OpenPGP_signature (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22343
; Package
emacs
.
(Fri, 03 Dec 2021 16:28:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 22343 <at> debbugs.gnu.org (full text, mbox):
Clément Pit-Claudel <clement.pitclaudel <at> live.com> writes:
> I cannot reproduce this issue any more.
Thanks for checking; I'm closing this bug report, then.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
22343 <at> debbugs.gnu.org and Clément Pit--Claudel <clement.pitclaudel <at> live.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 03 Dec 2021 16:28: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
.
(Sat, 01 Jan 2022 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.