bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

> Issues with rare use cases usually take many moons to emerge, but in
> this case the complaints started right away.  So it seems like the
> elimination of the loop interferes with non-rare use cases, which
> means we will probably be seeing much more of similar complaints in
> the future, including for stuff people do in their init files without
> too detailed understanding of the underlying machinery.

On the other hand, I haven't seen any additional cases since the first
two...

> I'd expect at least some of these case not easily solved, and in any
> case it's a nuisance to users and Lisp package developers.
>
> What's more, a similar loop still exists on w32, so we will have
> subtly different behavior on different platforms.
>
> Reinstating the loop, but without the danger of inflooping, could have
> taken care of these issues in advance.  Thus my proposal.

How about removing the delay from w32 as well, and implementing it in
lisp, then it will be easier to play with (by the way,
x_make_frame_visible in nsterm.m does not have any delay so we already
had different behaviour on different platforms).

--- c/lisp/frame.el
+++ i/lisp/frame.el
@@ -610,6 +610,15 @@ (defvar after-make-frame-functions nil
   "Functions to run after a frame is created.
 The functions are run with one arg, the newly created frame.")
 
+(defun wait-until-frame-is-visible (frame)
+  "Busy wait until FRAME is visible."
+  (let ((start-time (current-time)))
+    (while (and (not (frame-visible-p frame))
+                (< (float-time (subtract-time (current-time) start-time)) 1.0))
+      (sit-for 0.05))))
+
+(add-hook 'after-make-frame-functions #'wait-until-frame-is-visible)
+
 (defvar after-setting-font-hook nil
   "Functions to run after a frame's font has been changed.")