GNU bug report logs - #65191
29.1; -ms and -cr CL options don't work

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Peter Mao <peter.mao <at> gmail.com>
Cc: 65191 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#65191: 29.1; -ms and -cr CL options don't work
Date: Fri, 11 Aug 2023 14:22:25 +0800

Peter Mao <peter.mao <at> gmail.com> writes:

> On Thu, Aug 10, 2023 at 10:23 PM Po Lu <luangruo <at> yahoo.com> wrote:
>
>  Peter Mao <peter.mao <at> gmail.com> writes:
>
>  > On Thu, Aug 10, 2023 at 7:54 AM Peter Mao <peter.mao <at> gmail.com> wrote:
>  >
>  >  On Thu, Aug 10, 2023 at 12:21 AM Po Lu <luangruo <at> yahoo.com> wrote:
>  >
>  >  If you type:
>  >
>  >    M-x list-colors-display RET
>  >
>  >  does `green' appear in the resulting list?
>  >
>  >  I'll check when I get home tonight, but given that (set-cursor-color
>  >  "green") works, doesn't that indicate that the color is available?
>  >
>  > green, red, cyan and 545 others... 
>
>  What if you build Emacs without Cairo?  Does the problem subside then?
>
> Yes, that fixes the -cr issue!
>  
>  Also, what is printed when you run:
>
>    xrdb -query
>
> $ xrdb -query
> *customization: -color
> xscreensaver.Dialog.Button.background: #444
> xscreensaver.Dialog.Button.foreground: #EDEDFF
> xscreensaver.Dialog.background: #202020
> xscreensaver.Dialog.bodyFont: -*-dina-medium-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.Dialog.borderWidth: 0
> xscreensaver.Dialog.bottomShadowColor: #202024
> xscreensaver.Dialog.buttonFont: -*-dina-bold-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.Dialog.dateFont: -*-dina-medium-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.Dialog.foreground: #EDEDED
> xscreensaver.Dialog.headingFont: -*-dina-bold-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.Dialog.internalBorderWidth: 24
> xscreensaver.Dialog.labelFont: -*-dina-medium-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.Dialog.shadowThickness: 2
> xscreensaver.Dialog.text.background: #444
> xscreensaver.Dialog.text.foreground: #EDEDFF
> xscreensaver.Dialog.topShadowColor: #202024
> xscreensaver.Dialog.unameFont: -*-dina-medium-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.dateFormat: %I:%M%P %a %b %d, %Y
> xscreensaver.passwd.passwdFont: -*-dina-bold-r-*-*-10-*-*-*-*-*-*-*
> xscreensaver.passwd.thermometer.background: #202020
> xscreensaver.passwd.thermometer.foreground: #A9B7C4
> xscreensaver.passwd.thermometer.width: 8
> Xft.hintstyle: hintnone
> Xft.rgba: none
> Xcursor.theme: 
> Xcursor.size: 0
> Xcursor.theme_core: 

I tracked this down to the Cairo xsettings stuff, and uncovered a
fundamental problem with it in the process.  

Our settings code operates on FreeType font patterns, but the conversion
from Cairo is a one-way process: Emacs cannot impart the new settings it
reads to Cairo, so every time it registers a settings event, it compares
the new settings with whatever Cairo used as its defaults from the very
outset.  Consequentially, the dynamic-setting stuff is always run every
time a settings change event arrives, even if the changes are congruent
with what Emacs last saw of them.  dynamic-setting subsequently resets
the cursor color, because face-set-after-frame-default calls
face-spec-recalc prior to reapplying frame parameters, which sets the
cursor face's background to black, culminating in
face-set-after-frame-default calling:

  (set-face-attribute 'cursor frame :background "black")

This issue is also the cause of bug#64809 and another bug.  So I would
like to revert the entirety of the Cairo dynamic-setting support, since
it's relatively pointless for Emacs to respond to settings change events
when it cannot save those settings.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.