bug#16064: 24.3.50; emacsclient fails on remote X session

["Óscar Fuentes" <ofv@wanadoo.es>]

[My ISP refuses to send email to 16064@debbugs.gnu.org so I'm posting on
the mailing list through gmane. Hope this is not lost.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> My crystal ball tells me that "echo $XAUTHORITY" in the above shell
> session does not give you the same answer as M-: (getenv "XAUTHORITY") RET

"echo $XAUTHORITY" prints nothing, and (getenv "XAUTHORITY") returns
nil.

> IOW it's a pain in the ass introduced by gdm3.  Please complain loudly,
> so that maybe at some point they'll see that the "solution" they chose
> is worse than the problem they tried to fix.

gdm3 is not installed here (this is a Kubuntu system,) and if anyone
thinks on the famous GTK bug that prevents remote Emacs terminals,
please note that this Emacs uses Lucid.

This worked for a long time but it is the first time that I need to use
a remote session since more than a year ago, so it is either something
introduced by an OS upgrade or by Emacs. I'll try to bisect it (which is
pain because IIRC the build method changed on this timeframe plus the
Emacs VC graph used to be a mess.)

Some more random data points:

$ emacs -nw

M-: (make-frame (list '(window-system . X)))
Debug entered-Lisp error: (error "Don't know how to create a frame on
window system X")

M-x abort-recursive-edit

M-: (make-frame (list '(window-system . X) (dispay . ":1124")))
Debug entered-Lisp error: (void-function display)

> My crystal ball stayed mute for this one, sorry,

No need to be sorry. Thanks for trying.