[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`
From: |
martin rudalics |
Subject: |
bug#77985: 31.0.50; infinite loop in `make-frame-names-alist` |
Date: |
Tue, 29 Apr 2025 10:37:13 +0200 |
User-agent: |
Mozilla Thunderbird |
> 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
Description: Text Data
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, Al Haji-Ali, 2025/04/22
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, Eli Zaretskii, 2025/04/26
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, martin rudalics, 2025/04/26
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, Eli Zaretskii, 2025/04/26
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, martin rudalics, 2025/04/26
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, Al Haji-Ali, 2025/04/27
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, martin rudalics, 2025/04/27
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, martin rudalics, 2025/04/27
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, Al Haji-Ali, 2025/04/28
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`,
martin rudalics <=
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, Al Haji-Ali, 2025/04/29
- bug#77985: 31.0.50; infinite loop in `make-frame-names-alist`, martin rudalics, 2025/04/30