bug#67628: Emacs 29.1: (x-open-connection (getenv "DISPLAY")) gets "Display :0.0 does not exist" error

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Herman <mahlamytsike@gmail.com>,  67628@debbugs.gnu.org
> Date: Tue, 05 Dec 2023 20:37:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If in 29.1 now 
> >> $ emacs --daemon -Q
> >> $ emacsclient -e "(setq debug-on-error t)"
> >> then 
> >> $ emacsclient -e "(make-frame-on-display (getenv \"DISPLAY\"))"
> >> does not give an error, i.e. the display is found
> >> 
> >> but if
> >> $ emacs --daemon -Q
> >> $ emacsclient -e "(setq debug-on-error t)"
> >> then
> >> $ emacsclient -e "(x-open-connection (getenv \"DISPLAY\"))"
> >> gives an error, i.e. the display does not exist.
> >
> > Po Lu, any ideas or suggestions?
> 
> The display is opened successfully, but the next event to arrive
> activates the dynamic-setting machinery that calls get-device-terminal,
> which signals an error in response to there being no frames on that
> display at the time.

So you are saying that this is an issue with the fine timing of when
the event arrives?  And if it arrived a bit later, it would have been
processed correctly?

> The sound fix is for get-device-terminal to search for the device
> provided within x_display_list instead of the list of live frames.

I'm not sure this is the correct fix.  If a frame is not yet in the
list of live frames exposed to Lisp, it might mean the frame is not
yet fully set up, and some code running off the dynamic-setting
machinery could similarly fail, right?

Wouldn't it be better to delay the processing of this event until the
frame is fully set?