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

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

[Dimitrios Apostolou]

GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30) of 2018-06-26

I have set the Xresource *reverseVideo to true, and as expected emacs 
reverses the colours when launched under X, and does not when launched 
with -nw thus keeping the terminal colour selections.

However emacsclient obeys the Xresources even when launched with -nw. This 
leads to colour reversal in text mode, which is unwanted since the xterm 
has already been configured as desired.

It seems the reason is that emacs-server loads the Xresources and sets 
some internal state that instructs all new emacsclient instances to 
reverse colours, regardless of them being an X client app or not.


A very quick way to reproduce and see the different behaviour of emacs and 
emacsclient is to run the following commands:

emacs -xrm 'emacs*reverseVideo: true' --exec \
      '(progn (setq server-name "reverseVideo_TRUE_server")
              (server-start)
              (insert server-name))' &
emacs -xrm 'emacs*reverseVideo: false' --exec \
      '(progn (setq server-name "reverseVideo_FALSE_server")
              (server-start)
              (insert server-name))' &
sleep 2
xterm -e emacsclient -nw -s reverseVideo_TRUE_server  &
xterm -e emacsclient -nw -s reverseVideo_FALSE_server &


Credits to Javier who posted this script at [1]. Please read the full 
thread for more information on the topic.

[1] http://lists.gnu.org/archive/html/help-gnu-emacs/2018-09/msg00193.html


Thanks,
Dimitris

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

[Lars Ingebrigtsen]

Dimitrios Apostolou <jimis@gmx.net> writes:

> I have set the Xresource *reverseVideo to true, and as expected emacs
> reverses the colours when launched under X, and does not when launched
> with -nw thus keeping the terminal colour selections.
>
> However emacsclient obeys the Xresources even when launched with
> -nw. This leads to colour reversal in text mode, which is unwanted
> since the xterm has already been configured as desired.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This behaviour is still present in Emacs 29.  This seems to be stemming
from this:

  ;; Check the reverseVideo resource.
  (let ((case-fold-search t))
    (let ((rv (x-get-resource "reverseVideo" "ReverseVideo")))
      (if (and rv
	       (string-match "^\\(true\\|yes\\|on\\)$" rv))
	  (setq default-frame-alist
		(cons '(reverse . t) default-frame-alist)))))

in term/x-win.el -- it sets reverse for all new frames, so when the -nw
frame appears, it also gets reverted (which isn't what we want, I
think).

If I just remove this, then everything still works fine (and the -nw
client problem disappears), because:

(defun x-handle-reverse-video (frame parameters)
  "Handle the reverse-video frame parameter and X resource.
`x-create-frame' does not handle this one."
  (when (cdr (or (assq 'reverse parameters)
		 (let ((resource (x-get-resource "reverseVideo"
						 "ReverseVideo")))

So it's always handled anyway, and the default-frame-alist setting is
just counter-productive, I think?

Does anybody see any possible negative consequences of just removing
that code from x-win.el?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> Cc: 32921@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 18 May 2022 14:38:33 +0200
> 
> Dimitrios Apostolou <jimis@gmx.net> writes:
> 
> > I have set the Xresource *reverseVideo to true, and as expected emacs
> > reverses the colours when launched under X, and does not when launched
> > with -nw thus keeping the terminal colour selections.
> >
> > However emacsclient obeys the Xresources even when launched with
> > -nw. This leads to colour reversal in text mode, which is unwanted
> > since the xterm has already been configured as desired.
> 
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
> 
> This behaviour is still present in Emacs 29.  This seems to be stemming
> from this:
> 
>   ;; Check the reverseVideo resource.
>   (let ((case-fold-search t))
>     (let ((rv (x-get-resource "reverseVideo" "ReverseVideo")))
>       (if (and rv
> 	       (string-match "^\\(true\\|yes\\|on\\)$" rv))
> 	  (setq default-frame-alist
> 		(cons '(reverse . t) default-frame-alist)))))
> 
> in term/x-win.el -- it sets reverse for all new frames, so when the -nw
> frame appears, it also gets reverted (which isn't what we want, I
> think).
> 
> If I just remove this, then everything still works fine (and the -nw
> client problem disappears), because:
> 
> (defun x-handle-reverse-video (frame parameters)
>   "Handle the reverse-video frame parameter and X resource.
> `x-create-frame' does not handle this one."
>   (when (cdr (or (assq 'reverse parameters)
> 		 (let ((resource (x-get-resource "reverseVideo"
> 						 "ReverseVideo")))
> 
> So it's always handled anyway, and the default-frame-alist setting is
> just counter-productive, I think?
> 
> Does anybody see any possible negative consequences of just removing
> that code from x-win.el?

Which sequence of calls ends up calling x-handle-reverse-video, and
what is the trigger for that sequence of calls?

(These kinds of changes in code that was there for decades give me the
creeps.)

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

[Lars Ingebrigtsen]

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()

> (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.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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).

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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?

Yes, it would change that behaviour...  but I think we'd want that?  If
the user changes reverseVideo, then I think it's natural to expect
subsequent frames to heed that.  (Not that I think that's very
important -- people generally don't do that.)

> 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.

Yes, a default-frame-parameters-for-window-system (or something like
that) variable might make sense in general.  Then users could specify
these things separately for TTY and GUI.

But are there many parameters like this?  Most of the frame parameters
are ignored on TTY...

>> 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).

I see.  I wondered whether this was for using X servers under Windows,
somehow...  (I think that existed a long time ago, at least?)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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:52:21 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> Yes, it would change that behaviour...  but I think we'd want that?  If
> the user changes reverseVideo, then I think it's natural to expect
> subsequent frames to heed that.  (Not that I think that's very
> important -- people generally don't do that.)

It's a change in long-standing behavior, and someone out there is
bound to want it.

> > 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.
> 
> Yes, a default-frame-parameters-for-window-system (or something like
> that) variable might make sense in general.  Then users could specify
> these things separately for TTY and GUI.
> 
> But are there many parameters like this?  Most of the frame parameters
> are ignored on TTY...

Many are ignored, but some are relevant:

  . foreground and background colors
  . cursor blinking
  . menuBar
  . tabBar

> > Yes, we emulate X resources using the Registry on MS-Windows (although
> > I think this is largely unknown and unused).
> 
> I see.  I wondered whether this was for using X servers under Windows,
> somehow...  (I think that existed a long time ago, at least?)

It did?  I only know about X servers used to run X programs from
remote Unix hosts.  And there's a Cygwin build of Emacs, of course,
but that runs as if on a Unix host.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, it would change that behaviour...  but I think we'd want that?  If
> the user changes reverseVideo, then I think it's natural to expect
> subsequent frames to heed that.  (Not that I think that's very
> important -- people generally don't do that.)

Changing X resources while Emacs is running is impossble anyway without
reconnecting to that display, since we run through various resource
databases, add our own resources, and merge them into a single database
later, instead of using any of them as-is.

What we actually need is not to remove that code, but to add a
terminal-local version of `default-frame-alist': as-is I think the code
will probably also end up overwriting the default value of
`inverse-video' when connecting to a new display with a different value
of that resource.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Thu, 19 May 2022 09:37:50 +0800
> 
> What we actually need is not to remove that code, but to add a
> terminal-local version of `default-frame-alist': as-is I think the code
> will probably also end up overwriting the default value of
> `inverse-video' when connecting to a new display with a different value
> of that resource.

It cannot be terminal-local, I think, because we want it to be in
effect for future terminals as well.

In frameset.el, we have a solution for a similar problem: instead of
setting the literal frame-parameter PARAM, we set a specially-named
parameter GUI:PARAM.  Then, when we need to actually create a frame,
we consult those GUI:PARAM parameters, and apply them as needed.

So my proposal is to modify window-system-initialization in x-win.el
to define special XRESOURCE:FOO parameters in default-frame-alist,
instead of defining FOO parameters themselves, and then change the GUI
frame-parameter handlers to define the FOO parameters from the values
of those XRESOURCE:FOO parameters.  (We only need this special
handling for frame parameters that are not ignored on TTY frames.)

Does this make sense?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> It cannot be terminal-local, I think, because we want it to be in
> effect for future terminals as well.

But why?  Under X, the resource database loaded by Emacs is normally
specific to each display.  (Emacs only loads the users X resource file
manually if it was never previously loaded into the X server.)  I think
what the code in x-win.el does means that only one display's
`reverseVideo' resource will be respected at any given time, while each
display's X resources are documented to only apply to frames created on
that display.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Thu, 19 May 2022 15:47:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It cannot be terminal-local, I think, because we want it to be in
> > effect for future terminals as well.
> 
> But why?  Under X, the resource database loaded by Emacs is normally
> specific to each display.  (Emacs only loads the users X resource file
> manually if it was never previously loaded into the X server.)  I think
> what the code in x-win.el does means that only one display's
> `reverseVideo' resource will be respected at any given time, while each
> display's X resources are documented to only apply to frames created on
> that display.

We may be miscommunicating.  The offending code in x-win.el is called
at startup, only once, and sets up default-frame-alist for all the
future frames, including those on displays this Emacs session did not
yet open and knows nothing about.  How would you define
default-frame-alist that is specific to those as-yet-unknown displays?

And if you are saying that the code in x-win.el should only affect the
display on which Emacs was started, then that would be an even more
seriously breaking change.  Why should we assume that the user
intended his/her X resources to be only honored on the (random)
display where Emacs shows its first frame?  The files ~/.Xresources
and ~/.Xdefaults are not specific to any display, AFAIU, they are
global for the user.  Right?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> We may be miscommunicating.  The offending code in x-win.el is called
> at startup, only once, and sets up default-frame-alist for all the
> future frames, including those on displays this Emacs session did not
> yet open and knows nothing about.  How would you define
> default-frame-alist that is specific to those as-yet-unknown displays?

I would leave it empty.

> And if you are saying that the code in x-win.el should only affect the
> display on which Emacs was started, then that would be an even more
> seriously breaking change.  Why should we assume that the user
> intended his/her X resources to be only honored on the (random)
> display where Emacs shows its first frame?  The files ~/.Xresources
> and ~/.Xdefaults are not specific to any display, AFAIU, they are
> global for the user.  Right?

Emacs _never_ honored any other X resource that happened to be on the
first display for every display, and I have a feeling this code was a
mistake left over from the refactoring of `x-win.el' when multi-TTY was
developed.

Emacs, like all other X programs, takes resources from several different
sources:

  - The system's locale-specific X resources.  This is normally empty on
    modern systems.

  - The user's personal X resource files for Emacs.  This is also mostly
    empty on modern systems.

  - The user's X defaults that were loaded into the X server.  Only if
    the no X resources were loaded into the X server will Emacs try to
    load them itself from ~/.Xdefaults.

  - The environment defaults.  Also empty on modern systems.

This is why X resources are typically specific to each X server, which
is also why Emacs keeps a different resource database for each display
connection, and does not try to apply resources (other than
`reverseVideo') from one display connection to another.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Thu, 19 May 2022 16:59:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We may be miscommunicating.  The offending code in x-win.el is called
> > at startup, only once, and sets up default-frame-alist for all the
> > future frames, including those on displays this Emacs session did not
> > yet open and knows nothing about.  How would you define
> > default-frame-alist that is specific to those as-yet-unknown displays?
> 
> I would leave it empty.

That means we stop supporting X resources, more or less.

> > And if you are saying that the code in x-win.el should only affect the
> > display on which Emacs was started, then that would be an even more
> > seriously breaking change.  Why should we assume that the user
> > intended his/her X resources to be only honored on the (random)
> > display where Emacs shows its first frame?  The files ~/.Xresources
> > and ~/.Xdefaults are not specific to any display, AFAIU, they are
> > global for the user.  Right?
> 
> Emacs _never_ honored any other X resource that happened to be on the
> first display for every display, and I have a feeling this code was a
> mistake left over from the refactoring of `x-win.el' when multi-TTY was
> developed.

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?

> Emacs, like all other X programs, takes resources from several different
> sources:
> 
>   - The system's locale-specific X resources.  This is normally empty on
>     modern systems.
> 
>   - The user's personal X resource files for Emacs.  This is also mostly
>     empty on modern systems.
> 
>   - The user's X defaults that were loaded into the X server.  Only if
>     the no X resources were loaded into the X server will Emacs try to
>     load them itself from ~/.Xdefaults.
> 
>   - The environment defaults.  Also empty on modern systems.
> 
> This is why X resources are typically specific to each X server, which
> is also why Emacs keeps a different resource database for each display
> connection, and does not try to apply resources (other than
> `reverseVideo') from one display connection to another.

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.

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?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Thu, 19 May 2022 18:19:43 +0800
> 
> 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.

We already do that, see the information and the backtrace posted by
Lars a while ago.

The code in x-win.el does something beyond that: it caters for people
who have X resources specified on their user-private files, and want
those settings to be in effect on all displays.

(And besides, what is the chance that someone will want different
values of reverseVideo on different displays?  I think the chances for
that are nil.)

> > 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?

Because we will otherwise break a long-standing behavior.

> 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.

People who want Emacs to behave like you describe can simply remove
this setting from their ~/.Xdefaults.

> > 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.

Not necessarily, because frame-parameters applied by
gui_default_parameter could override those we took from ~/.Xdefaults.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> We already do that, see the information and the backtrace posted by
> Lars a while ago.

Hmm... then why does this code still exist at all?
x-create-frame-with-faces should take care of setting the `reverse'
parameter entirely.

Could you please explain what you meant by "startup timer" here?

> 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?

Though I doubt this really matters, since X resources cannot change
after Emacs starts.

> The code in x-win.el does something beyond that: it caters for people
> who have X resources specified on their user-private files, and want
> those settings to be in effect on all displays.

But then why only a single resource, and not all of them?  Especially
an obscure one like reverseVideo?

BTW, I think I found out why this situation is.  Before Emacs 19.29,
reverseVideo and selectionTimeout were both set up in x-win.el assuming
that there would only ever be a single display, just like the other
frame parameters in Fx_create_frame.

When support for multiple displays was added in 19.29, the changes to
make X resources affecting frame parameters specific to each display
were made to the C code in Fx_create_frame, but not to the two
parameters set in Lisp.  Whether or not that was done intentionally is
anyone's guess, but I think it was a bug, or an oversight.

> (And besides, what is the chance that someone will want different
> values of reverseVideo on different displays?  I think the chances for
> that are nil.)

Many other programs accept a resource named reverseVideo (it and -rv are
a very standard knobs for X programs), so I can imagine someone placing:

  *.reverseVideo: on

in the X resources for an X server with dark window decorations, and
vice versa.  Emacs should create frames with the colors specified on
each server it is connected to.

> Because we will otherwise break a long-standing behavior.

[...]

> People who want Emacs to behave like you describe can simply remove
> this setting from their ~/.Xdefaults.

That wouldn't be useful, since Emacs doesn't even load ~/.Xdefaults if
the X server it connected to already has some resources loaded.  Doing
that is the job of the session script(s) that started the X server.

> Not necessarily, because frame-parameters applied by
> gui_default_parameter could override those we took from ~/.Xdefaults.

I meant the parameters applied by gui_default_parameter when the
parameter is not present in `default-frame-alist' or the ALIST argument.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Thu, 19 May 2022 21:09:51 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We already do that, see the information and the backtrace posted by
> > Lars a while ago.
> 
> Hmm... then why does this code still exist at all?

That's what we are trying to understand, among other things.  I posted
one possible explanation.

> x-create-frame-with-faces should take care of setting the `reverse'
> parameter entirely.

I'm not sure this is 100% true.

> Could you please explain what you meant by "startup timer" here?
> 
> > 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?

It's a typo: I meant "at startup time".

> > The code in x-win.el does something beyond that: it caters for people
> > who have X resources specified on their user-private files, and want
> > those settings to be in effect on all displays.
> 
> But then why only a single resource, and not all of them?  Especially
> an obscure one like reverseVideo?

I don't know.  I guess for some kind of backward compatibility.  This
is very old code.

> > People who want Emacs to behave like you describe can simply remove
> > this setting from their ~/.Xdefaults.
> 
> That wouldn't be useful, since Emacs doesn't even load ~/.Xdefaults if
> the X server it connected to already has some resources loaded.

You assume that those hypothetical people didn't take care of that.

> > Not necessarily, because frame-parameters applied by
> > gui_default_parameter could override those we took from ~/.Xdefaults.
> 
> I meant the parameters applied by gui_default_parameter when the
> parameter is not present in `default-frame-alist' or the ALIST argument.

Then I don't understand your objection at all: when Emacs starts up,
there's only one X server that can be relevant: the one where Emacs
shows its first frame.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> That's what we are trying to understand, among other things.  I posted
> one possible explanation.

I didn't really understand it, since there is no difference between
"startup time" and "frame creation time": the X resources as known to
Emacs do not change after the display connection is established.  They
might change on the MS Windows registry emulation, but not on X.

> I'm not sure this is 100% true.

Hmm, what other situations could there be?  Tooltip frames don't respect
`default-frame-alist' anyway, and I hope nobody out there is calling
`x-create-frame' directly.

> I don't know.  I guess for some kind of backward compatibility.  This
> is very old code.

My guess is that it was an oversight between 19.29 and 19.27.  But let's
see if anyone else knows what is going on.

> Then I don't understand your objection at all: when Emacs starts up,
> there's only one X server that can be relevant: the one where Emacs
> shows its first frame.

My objection was that it behaves differently from the other X resources,
in a way that is eventually overidden by `x-create-frame-with-faces'
anyway.

Thanks.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Thu, 19 May 2022 21:40:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's what we are trying to understand, among other things.  I posted
> > one possible explanation.
> 
> I didn't really understand it, since there is no difference between
> "startup time" and "frame creation time": the X resources as known to
> Emacs do not change after the display connection is established.  They
> might change on the MS Windows registry emulation, but not on X.

No, there is a difference: when we change default-frame-alist at
startup time, that change is thereafter propagated to all future
frames, independently of what frame-creation-function will do when
each new frame is created.

> > Then I don't understand your objection at all: when Emacs starts up,
> > there's only one X server that can be relevant: the one where Emacs
> > shows its first frame.
> 
> My objection was that it behaves differently from the other X resources,
> in a way that is eventually overidden by `x-create-frame-with-faces'
> anyway.

The reverseVideo resource, like the -rv command-line argument, is
supposed to invert the colors that the user's customizations set.
Maybe this is why it is handled specially.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But are there many parameters like this?  Most of the frame parameters
>> are ignored on TTY...
>
> Many are ignored, but some are relevant:
>
>   . foreground and background colors
>   . cursor blinking
>   . menuBar
>   . tabBar

Yes, I can see people wanting to have different frame parameters for
those in TTY vs. GUI, so I think it sounds like it would be worth
creating something here.  But it does look like a largish job -- we'd
have to go through all the places where default-frame-alist is altered
and see whether it should be window-system dependent or not.

For accesses, I think that's probably simpler: We could just replace all
instances where something is doing an `assq ... default-frame-alist'
with a helper function that does the right thing.

...

Oh!  `window-system-default-frame-alist' already exists!  Never mind.
So we could just alter the term/x-win code snippet.

(But I haven't read the rest of the thread here yet.)

>> I see.  I wondered whether this was for using X servers under Windows,
>> somehow...  (I think that existed a long time ago, at least?)
>
> It did?  I only know about X servers used to run X programs from
> remote Unix hosts.

Right, that must be what I vaguely remember, then -- it's been decades
since I encountered this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> And if you are saying that the code in x-win.el should only affect the
> display on which Emacs was started, then that would be an even more
> seriously breaking change.  Why should we assume that the user
> intended his/her X resources to be only honored on the (random)
> display where Emacs shows its first frame?  The files ~/.Xresources
> and ~/.Xdefaults are not specific to any display, AFAIU, they are
> global for the user.  Right?

As Po says, X resources are a per-display thing -- the user may have
wildly differing X resources on different displays, and the intention of
X is that programs should query the X resource database whenever a new
window (i.e., frame) is opened.

Which removing that code from x-win.el would do.

I think Po is right here -- that code snippet in x-win.el just looks
like a misunderstanding.  (We handle all other X resources correctly, it
just this one that we handle in this wrong manner.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> No, there is a difference: when we change default-frame-alist at
> startup time, that change is thereafter propagated to all future
> frames, independently of what frame-creation-function will do when
> each new frame is created.

But it seems that the `reverse' frame parameter is also only handled
inside `x-handle-reverse-video', so it only takes effect if the
frame-creation-function is eventually called:

    (defun x-handle-reverse-video (frame parameters)
      "Handle the reverse-video frame parameter and X resource.
    `x-create-frame' does not handle this one."
      (when (cdr (or (assq 'reverse parameters)
                     (let ((resource (x-get-resource "reverseVideo"
                                                     "ReverseVideo")))
                       (if resource
                           (cons nil (member (downcase resource)
                                             '("on" "true")))))))
          (let* ((params (frame-parameters frame))
                 (bg (cdr (assq 'foreground-color params)))
                 (fg (cdr (assq 'background-color params))))
            (modify-frame-parameters frame
                                     (list (cons 'foreground-color fg)
                                           (cons 'background-color bg)))
            (if (equal bg (cdr (assq 'border-color params)))
                (modify-frame-parameters frame
                                         (list (cons 'border-color fg))))
            (if (equal bg (cdr (assq 'mouse-color params)))
                (modify-frame-parameters frame
                                         (list (cons 'mouse-color fg))))
            (if (equal bg (cdr (assq 'cursor-color params)))
                (modify-frame-parameters frame
                                         (list (cons 'cursor-color fg)))))))

> The reverseVideo resource, like the -rv command-line argument, is
> supposed to invert the colors that the user's customizations set.
> Maybe this is why it is handled specially.

Hmm...

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Po Lu <luangruo@yahoo.com>,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Fri, 20 May 2022 01:04:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And if you are saying that the code in x-win.el should only affect the
> > display on which Emacs was started, then that would be an even more
> > seriously breaking change.  Why should we assume that the user
> > intended his/her X resources to be only honored on the (random)
> > display where Emacs shows its first frame?  The files ~/.Xresources
> > and ~/.Xdefaults are not specific to any display, AFAIU, they are
> > global for the user.  Right?
> 
> As Po says, X resources are a per-display thing -- the user may have
> wildly differing X resources on different displays, and the intention of
> X is that programs should query the X resource database whenever a new
> window (i.e., frame) is opened.
> 
> Which removing that code from x-win.el would do.
> 
> I think Po is right here -- that code snippet in x-win.el just looks
> like a misunderstanding.  (We handle all other X resources correctly, it
> just this one that we handle in this wrong manner.)

I object to removing that code without any trace.  We should resolve
the bug by adding the X resource derived reverseVideo argument to
window-system-default-frame-alist instead of default-frame-alist.  If
you still insist on changing the age-old behavior, then at least
provide a way for users who want that to have that behavior back
(which might not be easy, since we are talking about something that
happens at startup, but I think we load the user init file before
calling the window-system initialization?).

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Fri, 20 May 2022 09:04:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, there is a difference: when we change default-frame-alist at
> > startup time, that change is thereafter propagated to all future
> > frames, independently of what frame-creation-function will do when
> > each new frame is created.
> 
> But it seems that the `reverse' frame parameter is also only handled
> inside `x-handle-reverse-video', so it only takes effect if the
> frame-creation-function is eventually called:

Isn't that true for every parameter in default-frame-alist?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Isn't that true for every parameter in default-frame-alist?

Sorry, I didn't make myself very clear.  But I also misunderstood how
make-frame worked.  I meant to say x-handle-reverse-video always
overrides what we put in default-frame-alist anyway, or so I thought,
until a little digging revealed that make-frame would actually pass the
contents of default-frame-alist to the frame-creation-function.

In that case, why does gui_display_get_arg still have to search inside
Vdefault_frame_alist, since that information should already be inside
the ALIST argument, provided by make-frame?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I object to removing that code without any trace.  We should resolve
> the bug by adding the X resource derived reverseVideo argument to
> window-system-default-frame-alist instead of default-frame-alist.

That would still change relatively old behavior from the days of Emacs
23, where the parameter in question began to apply to TTY frames as
well.  But the "age-old behavior" is IMHO wrong enough that it's more
likely to be a bug from 19.29 (when support for multiple X displays was
introduced), as opposed to a feature.

> If you still insist on changing the age-old behavior, then at least
> provide a way for users who want that to have that behavior back
> (which might not be easy, since we are talking about something that
> happens at startup, but I think we load the user init file before
> calling the window-system initialization?).

window-system initialization is called before the user init file is
loaded, but the early-init file gets called before that, I think.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If you still insist on changing the age-old behavior, then at least
> provide a way for users who want that to have that behavior back
> (which might not be easy, since we are talking about something that
> happens at startup, but I think we load the user init file before
> calling the window-system initialization?).

I wondered whether it might make sense to have the x-win.el code snippet
stash the reverseVideo data in `initial-frame-alist', but I didn't
investigate what effect that would have (if any)...

But if we did that, then

  (push (assq 'reverse initial-frame-alist) default-frame-alist)

would be a way to get the current behaviour back, if somebody wanted it.
(But I haven't actually tested this.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Fri, 20 May 2022 16:19:50 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I object to removing that code without any trace.  We should resolve
> > the bug by adding the X resource derived reverseVideo argument to
> > window-system-default-frame-alist instead of default-frame-alist.
> 
> That would still change relatively old behavior from the days of Emacs
> 23, where the parameter in question began to apply to TTY frames as
> well.

Yes.  But ignoring X resources in TTY frames is much more defendable
change than ignoring them on all frames.

> But the "age-old behavior" is IMHO wrong enough that it's more
> likely to be a bug from 19.29 (when support for multiple X displays was
> introduced), as opposed to a feature.

What you consider a bug is nowadays a de-facto "feature", given how
much time Emacs behaved like that.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  32921@debbugs.gnu.org,  jimis@gmx.net
> Date: Fri, 20 May 2022 10:28:15 +0200
> 
> I wondered whether it might make sense to have the x-win.el code snippet
> stash the reverseVideo data in `initial-frame-alist', but I didn't
> investigate what effect that would have (if any)...

initial-frame-alist is only for the initial frame shown by Emacs.  So
making that change is also a significant change in behavior.

Moreover, I don't really see the rationale for such a change?  Why
consider the X resources applicable to the initial frame, but not to
the consequent ones?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Moreover, I don't really see the rationale for such a change?  Why
> consider the X resources applicable to the initial frame, but not to
> the consequent ones?

I just thought of that a place to stash the darn thing, if we wanted to
make it possible for users to retrieve it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> in term/x-win.el -- it sets reverse for all new frames, so when the -nw
> frame appears, it also gets reverted (which isn't what we want, I
> think).
>
> If I just remove this, then everything still works fine (and the -nw
> client problem disappears), because:

[...]

> So it's always handled anyway, and the default-frame-alist setting is
> just counter-productive, I think?
>
> Does anybody see any possible negative consequences of just removing
> that code from x-win.el?

Much discussion ensued after this, and there's good arguments on both
sides.  I.e., this is long standing (if odd behaviour), so it might
annoy people to change this.  However, it is a real bug -- i.e., we
handle the reverseVideo X resource in a really abnormal way, like we
handle no other X resources, so I think we should fix it anyway.

So I've now done that in Emacs 29, and added a NEWS entry saying that
this is backwards incompatible.  We'll see whether anybody complaints.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no