Subject: Re: bug#13339: 24.3.50; doc of `next-frame'

From: Lars Ingebrigtsen <[email-masked]>
Date: Mon, 23 Aug 2021 16:32:03 +0200

"Drew Adams" <[email-masked]> writes:

> What is unclear is which frames are _included_ in this case.  The only
> thing we are told is that minibuffer-only frames are _excluded_.  Does
> that mean that all other frames are included?  Or only visible frames?
> Or only visible or iconified frames?

Looking at the code, it's absolutely all frames on that terminal.  I've
now adjusted the doc string and the manual.

"Drew Adams" <[email-masked]> writes:

> BTW, the doc of `other-frame' says that it includes _visible_ frames.
> And its code calls `next-frame' with a nil value for argument
> MINIFRAME.  So if the doc of `other-frame' is correct then the
> `next-frame' with nil MINIFRAME must include only visible frames, not
> all frames except minibuffer-only frames and not all visible or
> iconified frames except minibuffer-only frames.

I haven't dug into the code history here, but the code today says:

    (while (> arg 0)
      (setq frame (next-frame frame))
      (while (and (not (eq frame sframe))
                  (not (eq (frame-visible-p frame) t)))
	(setq frame (next-frame frame)))
      (setq arg (1- arg)))

So the doc string of `other-frame' is correct.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no