bug#65191: 29.1; -ms and -cr CL options don't work

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  65191@debbugs.gnu.org
> Date: Fri, 11 Aug 2023 14:22:25 +0800
> 
> 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.

I don't think I understand this well enough to discuss this
intelligently, so please elaborate on what happens, and include
pointers to more of the code so I and others could complement the
descriptions with what's actually in the code, and maybe suggest
alternative ways of dealing with this.

Not responding to Cairo setting changes sounds like a loss: what
features are currently based on that, and would be lost if we revert
this support?  Also, can't you think about an alternative way of
handling dynamic settings that will let us eat the cake, but also have
it?

Thanks.