one-window-p with no args no good for standalone minibuffer frame

one-window-p with no args no good for standalone minibuffer frame

[Drew Adams]

My reading of the doc string for `one-window-p says that
(one-window-p) should be the same as (one-window-p nil 'foobar), when
it is evaled in a standalone minibuffer frame and the minibuffer is
active. But it is not. The latter gives the correct result, t; the
former returns nil.

For instance, with a standalone minibuffer frame and active
minibuffer, this code should return t, just as it does if
(one-window-p nil 'foobar) is used in it:

(and (active-minibuffer-window)
     (save-selected-window
       (select-window (minibuffer-window))
       (one-window-p)))

The problem, I think, is that `one-window-p' just passes its
ALL-FRAMES arg to `next-window', and `next-window' does not treat its
ALL-FRAMES arg the same as (what the doc string states for)
`one-window-p'.

The doc string of `one-window-p' says this for arg ALL-FRAMES:
"ALL-FRAMES nil or omitted means count only the selected frame, plus
the minibuffer it uses (which may be on another frame)." To me, that
means it should count only the standalone minibuffer frame.

The doc string of `next-window' says that nil ALL-FRAMES means to
cycle among all frames that use the same minibuffer (whenever the
minibuffer counts, which it does when it is active). That is incorrect
behavior for `one-window-p', and it might even be incorrect behavior
for `next-window': In a standalone minibuffer, I would not expect
`next-window' with nil ALL-FRAMES to return a window on another frame.

BTW, I don't understand why the sexp (if nomini 'arg) is used in the
definition of `one-window-p'.  Why is the special value `arg' (or nil)
passed, instead of just the value of NOMINI?


In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'

RE: one-window-p with no args no good for standalone minibuffer frame

[Drew Adams]

Resending.  Anyone have an explanation for this?  Thx.

> From: Drew Adams Sent: Wednesday, November 21, 2007 1:09 PM 
> My reading of the doc string for `one-window-p says that
> (one-window-p) should be the same as (one-window-p nil 'foobar), when
> it is evaled in a standalone minibuffer frame and the minibuffer is
> active. But it is not. The latter gives the correct result, t; the
> former returns nil.
> 
> For instance, with a standalone minibuffer frame and active
> minibuffer, this code should return t, just as it does if
> (one-window-p nil 'foobar) is used in it:
> 
> (and (active-minibuffer-window)
>      (save-selected-window
>        (select-window (minibuffer-window))
>        (one-window-p)))
> 
> The problem, I think, is that `one-window-p' just passes its
> ALL-FRAMES arg to `next-window', and `next-window' does not treat its
> ALL-FRAMES arg the same as (what the doc string states for)
> `one-window-p'.
> 
> The doc string of `one-window-p' says this for arg ALL-FRAMES:
> "ALL-FRAMES nil or omitted means count only the selected frame, plus
> the minibuffer it uses (which may be on another frame)." To me, that
> means it should count only the standalone minibuffer frame.
> 
> The doc string of `next-window' says that nil ALL-FRAMES means to
> cycle among all frames that use the same minibuffer (whenever the
> minibuffer counts, which it does when it is active). That is incorrect
> behavior for `one-window-p', and it might even be incorrect behavior
> for `next-window': In a standalone minibuffer, I would not expect
> `next-window' with nil ALL-FRAMES to return a window on another frame.
> 
> BTW, I don't understand why the sexp (if nomini 'arg) is used in the
> definition of `one-window-p'.  Why is the special value `arg' (or nil)
> passed, instead of just the value of NOMINI?
> 
> 
> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
>  of 2007-06-02 on RELEASE
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags 
> -Ic:/gnuwin32/include'