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

[Noam Postavsky <npostavs@users.sourceforge.net>]

martin rudalics <rudalics@gmx.at> writes:

> I would add to NEWS something like "'select-frame-by-name' now may
> return a frame on another display if it does not find a suitable one on
> the current display".

Sure.

> Is there anything I could tweak here to observe a visible impact?  If I
> set ‘x-wait-for-event-timeout’ to some large value nothing becomes
> noticeable here, apparently because the frame is created fast enough.

I think you might have to change window managers.  For instance, when
using i3, adding 'assign [class="Emacs"] 9' to ~/.i3/config will make
Emacs frames show up in workspace 9.  When calling make-frame-command
from a different workspace, Emacs will not get the message about frame
visibility until you switch to workspace 9.

    (let ((x-wait-for-event-timeout nil))
      (benchmark 1 '(make-frame-command)))"Elapsed time: 0.083540s"
    (let ((x-wait-for-event-timeout 0.1)) ; default
      (benchmark 1 '(make-frame-command)))"Elapsed time: 0.169369s"
    (let ((x-wait-for-event-timeout 100.0))
      (benchmark 1 '(make-frame-command)))"Elapsed time: 1.338770s (0.052083s in 1 GCs)"

Hmm, that is actually less effect than I expected.  I recall now that
some non-relevant MapNotify events get sent in this case [1].  These
make x_wait_for_event (f, MapNotify) return earlier than the previous
busy wait.

Should we wrap a timeout loop around the x_wait_for_event call?  Or make
the wait more selective (e.g., check that the given frame matches)?
Seems a bit like overkill considering that a timeout of longer than 1
second is unlikely to be wanted, on the other hand, we're not really
waiting for the right thing...

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24091#57


> (3) Install the ‘select-frame-by-name’ patch on the release branch.
>
> The reason why I think that (3) is good to have despite of (1) is that
> functions would behave reasonably well on systems where the user sets
> the timeout to zero.  Thus people who, for some reason, cannot or do not
> want a larger timeout have a fallback.  Differently put: A timeout of
> zero should work well as default too.

Yes, I agree with this.