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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 77985 <at> debbugs.gnu.org
Subject: bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`
Date: Tue, 29 Apr 2025 10:37:13 +0200

[Message part 1 (text/plain, inline)]

> This patch passed all my, admittedly limited, test cases.

Thanks for checking.

> In the patch, `make-frame-names-alist` returns only frames on the same
> display. I don't know if this is a behaviour change or to make it
> consistent with `next-frame` (the doc of `next-frame` doesn't mention
> displays -- might worth clarifying there if this is the behaviour).

Thanks for spotting this.  'make-frame-names-alist' didn't have a
doc-string.  It only contained the comment

  ;; Only consider the frames on the same display.

so I thought that was the intended behavior.  In fact it wasn't so I
changed that now.

> Another minor/unimportant point (feel free to ignore) is that the
> patch also allows `make-frame-names-alist` to accept a FRAME
> argument. I think it would be more natural to return frames on the
> same display as the passed FRAME rather than the selected one.

I added the "(&optional frame)" because with a few exceptions most
frame-related functions have it so coders don't have to think twice when
calling any of these functions.

I attach a new version which also implements 'frame-list-1' in a
different way.  It's illustrative to look into how 'frame-list' and
'frame-list-1' relate.  With the following

(defun make-frames (number)
  (let ((i 0))
    (set-frame-parameter nil 'name (number-to-string (setq i (1+ i))))
    (while (< i number)
      (set-frame-parameter
       (make-frame) 'name (number-to-string (setq i (1+ i)))))))

make four frames via

(make-frames 4)

with titles "1" to "4".  Now when evaluating

(frame-list)
(frame-list-1)

the result for the latter will change when you switch to another frame
while the former remains unaltered.  I have no idea if it's that what we
want for 'make-frame-names-alist' but 'frame-list-1' should preserve the
old behavior.

Note here that we always list frames in the reverse order of their
creation.  This means that with respect to the selected frame,
'next-frame' conceptually returns the frame created previously and
'previous-frame' the one created next (unless these functions wrap
around, obviously) since both of these are based on the underlying
Vframe_list which is reproduced by 'frame-list'.

martin

[frame-list-1.diff (text/x-patch, attachment)]

Previous Next

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