Subject: bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`

From: martin rudalics <[email-masked]>
Date: Wed, 30 Apr 2025 11:47:10 +0200

> Am I right in saying that `frame-list-1` is only currently being used
 > in `make-frame-names-alist`, or did you mean to use it in other places
 > as well?

It could serve as template or substitute for anyone who uses
'next-frame' to get a list of frames and runs into an infinite loop.
Earlier Emacs versions will be still around for quite some time.

 > If that's the only place, I think this function is only
 > being used by `select-frame-by-name`. Both of these functions do not
 > stipulate an order in there docs, so I am not sure a particular
 > ordering is required?

IIUC 'select-frame-by-name' expects the frames created before the
selected frame be proposed first.  With plain 'frame-list' it would
always propose the most recently created frame - which would often be
the selected frame.  But I never use 'select-frame-by-name'.  Maybe you
can confirm that claim via say

(defun make-frame-names-alist (&optional frame)
   "Return alist of frame names and frames starting with FRAME.
Only visible or iconified frames are listed.  The optional argument
FRAME must specify a live frame and defaults to the selected frame."
   (let ((frames (frame-list))
	alist)
     (dolist (frame frames)
       (when (frame-visible-p frame)
	(push (cons (frame-parameter frame 'name) frame) alist)))
     (nreverse alist)))

 > Also a suggestion: if the ordering is indeed required, is there a
 > reason for defining a new function instead of changing `frame-list` to
 > take an argument (where the list starts), e.g., when passing nil the
 > order is not modified.

I contemplated that and found out that 'frame-list' may have to be
redesigned anyway to omit tooltip frames (and eventually also menubar
frames) on ttys and I'd like to resolve that issue before adding an
optional argument.

martin