* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
@ 2016-01-10 21:19 Clément Pit--Claudel
2016-01-11 18:56 ` Eli Zaretskii
2021-12-02 9:03 ` Lars Ingebrigtsen
0 siblings, 2 replies; 9+ messages in thread
From: Clément Pit--Claudel @ 2016-01-10 21:19 UTC (permalink / raw)
To: 22343
[-- Attachment #1.1: Type: text/plain, Size: 3972 bytes --]
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))
[-- Attachment #1.2: inconsistent-background-color.png --]
[-- Type: image/png, Size: 33755 bytes --]
[-- Attachment #1.3: magic-wand.png --]
[-- Type: image/png, Size: 109817 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
2016-01-10 21:19 bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources Clément Pit--Claudel
@ 2016-01-11 18:56 ` Eli Zaretskii
2016-01-11 19:09 ` Clément Pit--Claudel
2021-12-02 9:03 ` Lars Ingebrigtsen
1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2016-01-11 18:56 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 22343
> From: Clément Pit--Claudel <clement.pitclaudel@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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
2016-01-11 18:56 ` Eli Zaretskii
@ 2016-01-11 19:09 ` Clément Pit--Claudel
2016-01-11 19:14 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Clément Pit--Claudel @ 2016-01-11 19:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22343
[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]
On 01/11/2016 01:56 PM, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel@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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
2016-01-11 19:09 ` Clément Pit--Claudel
@ 2016-01-11 19:14 ` Eli Zaretskii
2016-01-12 2:20 ` Clément Pit--Claudel
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2016-01-11 19:14 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 22343
> Cc: 22343@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@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...
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
2016-01-11 19:14 ` Eli Zaretskii
@ 2016-01-12 2:20 ` Clément Pit--Claudel
2016-01-12 16:46 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Clément Pit--Claudel @ 2016-01-12 2:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22343
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
On 01/11/2016 02:14 PM, Eli Zaretskii wrote:
>> Cc: 22343@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@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?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
2016-01-12 2:20 ` Clément Pit--Claudel
@ 2016-01-12 16:46 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2016-01-12 16:46 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 22343
> Cc: 22343@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Mon, 11 Jan 2016 21:20:25 -0500
>
> On 01/11/2016 02:14 PM, Eli Zaretskii wrote:
> >> Cc: 22343@debbugs.gnu.org
> >> From: Clément Pit--Claudel <clement.pitclaudel@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources
2016-01-10 21:19 bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources Clément Pit--Claudel
2016-01-11 18:56 ` Eli Zaretskii
@ 2021-12-02 9:03 ` Lars Ingebrigtsen
2021-12-03 4:29 ` Clément Pit-Claudel
1 sibling, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-02 9:03 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 22343
Clément Pit--Claudel <clement.pitclaudel@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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-12-03 16:27 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-10 21:19 bug#22343: 25.0.50; Incorrect rounding (?) when loading the Emacs.background attribute from Xresources Clément Pit--Claudel
2016-01-11 18:56 ` Eli Zaretskii
2016-01-11 19:09 ` Clément Pit--Claudel
2016-01-11 19:14 ` Eli Zaretskii
2016-01-12 2:20 ` Clément Pit--Claudel
2016-01-12 16:46 ` Eli Zaretskii
2021-12-02 9:03 ` Lars Ingebrigtsen
2021-12-03 4:29 ` Clément Pit-Claudel
2021-12-03 16:27 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).