GNU bug report logs - #77985
31.0.50; infinite loop in `make-frame-names-alist`

Previous Next

Full log

Message #14 received at 77985 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: abdo.haji.ali <at> gmail.com, 77985 <at> debbugs.gnu.org
Subject: Re: bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`
Date: Sat, 26 Apr 2025 19:41:51 +0300

> Date: Sat, 26 Apr 2025 18:34:16 +0200
> Cc: 77985 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >> I am running into an infinite loop in the function `make-frame-names-alist` which is called from `select-frame-by-name`.
>  >>
>  >> The infinite loop happens when a frame with the property `no-other-frame` is the currently selected one. Starting with `emacs -Q`, the following code demonstrates the issue:
>  >>
>  >> (with-selected-frame (make-frame '((no-other-frame . t)))
>  >>      (make-frame-names-alist))
>  >
>  > Martin, any suggestions?
> 
> The same problem occurs with
> 
> (let ((frame (make-frame)))
>    (make-frame-invisible frame)
>    (with-selected-frame frame
>      (make-frame-names-alist)))
> 
> Both can be stopped via C-g here.
> 
> (progn
>    (set-frame-parameter nil 'no-other-frame t)
>    (delete-other-frames))
> 
> is worse.  C-g doesn't help here.
> 
> Inherently, these are siblings of Bug#15025.  Suggestions are:
> 
> - 'delete-other-frames' and ‘make-frame-names-alist’ signal an error
>    when the selected frame has a 'no-other-frame t parameter or is
>    invisible.  Simple.
> 
> - Have t for the MINIFRAME argument of 'next-frame' cycle through all
>    frames including invisible and 'no-other-frame frames.  Simple but
>    this would mean that 'make-frame-names-alist' would return the names
>    of invisible frames too (it could filter them out afterwards).
> 
> - Have 'make-frame-names-alist' and 'delete-other-frames' call
>    'frame-list' and iterate over it.  More robust but invasive.

What about detecting when we made a full circle through all the
candidate frames, and stopping at that point?  Is that feasible?

> Whatever we do, we probably should say that
> 
>      (while (not (eq frame current-frame))
> 	(setq frame (next-frame frame 0)))
> 
> can loop.

Sure, but here the loop is explicit in the looping program, so it
could prevent the infloop.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.