bug#32921: emacsclient obeys Xresources even when launched with -nw

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jimis@gmx.net,  32921@debbugs.gnu.org
> Date: Wed, 18 May 2022 15:13:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which sequence of calls ends up calling x-handle-reverse-video, and
> > what is the trigger for that sequence of calls?
> 
> It's:
> 
> Debugger entered: nil
>   x-handle-reverse-video(#<frame GNU Emacs at xo 0x55a6e4722360> 
> ((vertical-scroll-bars) (height . 53) (width . 81) (reverse . t) 
> (cursor-color . "red") (cursor-type . box) (mouse-color . "red") 
> (horizontal-scroll-bars)))
>   x-create-frame-with-faces(((vertical-scroll-bars) (height . 53) (width . 
> 81) (reverse . t) (cursor-color . "red") (cursor-type . box) (mouse-color . 
> "red") (horizontal-scroll-bars)))
>   #f(compiled-function (params) #<bytecode 
> -0x1d5f77f46341f751>)(((vertical-scroll-bars) (height . 53) (width . 81) 
> (reverse . t) (cursor-color . "red") (cursor-type . box) (mouse-color . 
> "red") (horizontal-scroll-bars)))
>   apply(#f(compiled-function (params) #<bytecode -0x1d5f77f46341f751>) 
> ((vertical-scroll-bars) (height . 53) (width . 81) (reverse . t) 
> (cursor-color . "red") (cursor-type . box) (mouse-color . "red") 
> (horizontal-scroll-bars)))
>   frame-creation-function(((vertical-scroll-bars) (height . 53) (width . 81) 
> (reverse . t) (cursor-color . "red") (cursor-type . box) (mouse-color . 
> "red") (horizontal-scroll-bars)))
>   make-frame()

So the difference is between (a) taking notice of the reverseVideo
resource at startup timer as opposed to (b) at frame creation time, is
that right?  If so, I think this might affect the use case whereby
someone changes the X resources after Emacs has already started, or
something?

> > (These kinds of changes in code that was there for decades give me the
> > creeps.)
> 
> Indeed.  I tried to do some VC history spelunking for why we're
> apparently checking reverseVideo redundantly in this way, but I came up
> short.

Maybe it would be safer to add a special frame-parameter which will
record the fact that some parameters came from X resources, and will
then refrain from applying those parameters to TTY frames?  Or maybe
we should have some other special construct in default-frame-alist
that prevents some parameters from being applied to TTY frames?
Because I think reverseVideo is just one example of such parameters.

> It might not be redundant on Windows, which presumably doesn't call
> these X functions, but does heed reverseVideo in the w32 version of
> window-system-initialization.

Yes, we emulate X resources using the Registry on MS-Windows (although
I think this is largely unknown and unused).