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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> How do you mean "never"?  We have here the code in x-win.el which does
> that and is very old, so "never" doesn't seem to be a good description
> of the situation.  And multi-TTY support has nothing to do with
> multiple X displays.  AFAIU, you suggested to take the X resources
> into consideration only for the first X display on which Emacs opens
> its first frame.  What does this have to do with multi-TTY?

No, I suggested to take the value of Emacs.reverseVideo of each display
(yes, they are different between different displays) into account only
for frames created that display.

> This is completely irrelevant.  We supported X resources in Emacs
> forever, and I see no reason to unsupport them now.  We need to
> discuss this under the assumption that ~/.Xresources and ~/.Xdefaults
> will continue to have the same effect on Emacs as they did before, at
> least optionally if not by default.  Thus, suggestions to toss that
> support are non-starters from where I stand.

Why?  My point was that X resources in Emacs are loaded from the X
server, and as such reverseVideo could be different from one display to
the other.  This works fine with frame parameters that are set with
gui_default_parameter, since that calls gui_display_get_resource with
the dpyinfo the frame is on.  However, the existing code applies the
value of reverseVideo of the first display to all frames, even those
created on subsequently opened displays, which means the `reverse' frame
parameter of those frames will not match the value of Emacs.reverseVideo
on any display other than the first display that was created.

> What about the suggestion to have specially-named frame parameters in
> default-frame-alist, which are defined from X resources and only
> applied to GUI frames?

That would work incorrectly if Emacs was connected to two different X
servers, each with different values of reverseVideo.