unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#13339: 24.3.50; doc of `next-frame'
@ 2013-01-02 18:56 Drew Adams
  2013-01-02 19:02 ` Drew Adams
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Drew Adams @ 2013-01-02 18:56 UTC (permalink / raw)
  To: 13339

The doc (both doc string and Elisp manual) is unclear for the default
case where argument MINIFRAME/MINIBUF is nil.  (BTW, the same parameter
name should be used here for the doc string and the manual.)
 
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?
 
Other values of this argument make clear which frames are included, but
the doc for a nil value of the argument is incomplete.
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-31 on ODIEONE
Bzr revision: 111388 rudalics@gmx.at-20121231113513-subz2dazg6yjukzh
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13339: 24.3.50; doc of `next-frame'
  2013-01-02 18:56 bug#13339: 24.3.50; doc of `next-frame' Drew Adams
@ 2013-01-02 19:02 ` Drew Adams
  2014-02-08 13:20 ` Lars Ingebrigtsen
  2021-08-23 14:32 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 5+ messages in thread
From: Drew Adams @ 2013-01-02 19:02 UTC (permalink / raw)
  To: 13339

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.

If that is not correct then there is thus also a doc bug for `other-frame'.  If
it is correct then that should help you correct the doc for `next-frame'.






^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13339: 24.3.50; doc of `next-frame'
  2013-01-02 18:56 bug#13339: 24.3.50; doc of `next-frame' Drew Adams
  2013-01-02 19:02 ` Drew Adams
@ 2014-02-08 13:20 ` Lars Ingebrigtsen
  2014-02-10 23:54   ` Drew Adams
  2021-08-23 14:32 ` Lars Ingebrigtsen
  2 siblings, 1 reply; 5+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-08 13:20 UTC (permalink / raw)
  To: Drew Adams; +Cc: 13339

"Drew Adams" <drew.adams@oracle.com> writes:

> The doc (both doc string and Elisp manual) is unclear for the default
> case where argument MINIFRAME/MINIBUF is nil.  (BTW, the same parameter
> name should be used here for the doc string and the manual.)
>
> 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?
>
> Other values of this argument make clear which frames are included, but
> the doc for a nil value of the argument is incomplete.

Uhm...  yeah...  clear.  >"?

Do you have a suggestion as to what the nil case should say?

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13339: 24.3.50; doc of `next-frame'
  2014-02-08 13:20 ` Lars Ingebrigtsen
@ 2014-02-10 23:54   ` Drew Adams
  0 siblings, 0 replies; 5+ messages in thread
From: Drew Adams @ 2014-02-10 23:54 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 13339

> Do you have a suggestion as to what the nil case should say?

It seems like the frames included then would be all frames on the
same terminal, other than FRAME and any minibuffer-only frames.

But see my followup message, which points out that the doc of
`other-frame' seems to suggest something quite different: only
_visible_ frames (on the same terminal...).

Probably someone more knowledgable should check the behavior
and make the fix.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#13339: 24.3.50; doc of `next-frame'
  2013-01-02 18:56 bug#13339: 24.3.50; doc of `next-frame' Drew Adams
  2013-01-02 19:02 ` Drew Adams
  2014-02-08 13:20 ` Lars Ingebrigtsen
@ 2021-08-23 14:32 ` Lars Ingebrigtsen
  2 siblings, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-23 14:32 UTC (permalink / raw)
  To: Drew Adams; +Cc: 13339

"Drew Adams" <drew.adams@oracle.com> 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" <drew.adams@oracle.com> 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





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-23 14:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-02 18:56 bug#13339: 24.3.50; doc of `next-frame' Drew Adams
2013-01-02 19:02 ` Drew Adams
2014-02-08 13:20 ` Lars Ingebrigtsen
2014-02-10 23:54   ` Drew Adams
2021-08-23 14:32 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).