window-list

window-list

[Karl Chen]

There's been a change in window-list that removes available
functionality: getting the list of windows in canonical order,
starting with the first window.  This is important functionality
that I depend on; I don't see any way to get it now through only
ELisp.

I propose the following change to window-list:
  WINDOW t means return the list unrotated (in canonical order)

Due to the call to decode_next_window_args() which should not
allow WINDOW t, the patch would be more than 2 or 3 lines if
decode_next_window_args() and the call to it from window_list_1()
were not changed.


Relevant ChangeLog entry:

2004-07-17  Richard M. Stallman  <rms@gnu.org>

        * window.c ...
        (window_list_1): Rotate the list to start with WINDOW.



-- 
Karl 2004-08-17 10:00

Re: window-list

[Kim F. Storm]

Karl Chen <quarl@nospam.quarl.org> writes:

> There's been a change in window-list that removes available
> functionality: getting the list of windows in canonical order,
> starting with the first window.  This is important functionality
> that I depend on; I don't see any way to get it now through only
> ELisp.
> 
> I propose the following change to window-list:
>   WINDOW t means return the list unrotated (in canonical order)
> 
> Due to the call to decode_next_window_args() which should not
> allow WINDOW t, the patch would be more than 2 or 3 lines if
> decode_next_window_args() and the call to it from window_list_1()
> were not changed.
> 
> 
> Relevant ChangeLog entry:
> 
> 2004-07-17  Richard M. Stallman  <rms@gnu.org>
> 
>         * window.c ...
>         (window_list_1): Rotate the list to start with WINDOW.


I don't recall any discussion about the need for that change, but
I guess there was a reason....

But I second your idea of using window=t to get the canonical list.


In any case, you can still get a canonical window list from lisp;
edebug does it like this --- you can probably tweak it to
your needs:

(defun edebug-window-list ()
  "Return a list of windows, in order of `next-window'."
  ;; This doesn't work for epoch.
  (let (window-list)
    (walk-windows (lambda (w) (push w window-list)))
    (nreverse window-list)))


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: window-list

[Luc Teirlinck]

Karl Chen wrote:

   There's been a change in window-list that removes available
   functionality: getting the list of windows in canonical order,
   starting with the first window.  This is important functionality
   that I depend on; I don't see any way to get it now through only
   ELisp.

What about:

(window-list frame minibuf (frame-first-window frame))

If FRAME is the selected frame this can be simplified to:

(window-list nil minibuf (frame-first-window))

Or am I misunderstanding the problem?

Sincerely,

Luc.

Re: window-list

[Luc Teirlinck]

Kim Storm wrote:

   I don't recall any discussion about the need for that change, but
   I guess there was a reason....

To make the function do what both its docstring and the documentation
in the Elisp manual claim it does:

 -- Function: window-list &optional frame minibuf window
     This function returns a list of the windows on FRAME, starting
     with WINDOW.  If FRAME is `nil' or omitted, the selected frame is
     used instead; if WINDOW is `nil' or omitted, the selected window
     is used instead.

So I do not believe that there _has_ been a change in documented
behavior.  The documentation was changed quite a while ago, for
"compatibility with XEmacs".  (Revision 1.322 to window.c on Nov 19,
2000, by Gerd.)  I guess the change must have been discussed back
then.  The new behavior was never correctly implemented, until
Richard's change.

As I already pointed out, unless I am misunderstanding, one can get
the behavior Karl wants, from Elisp, using:

(window-list frame minibuf (frame-first-window frame))

Sincerely,

Luc.

Re: window-list

[Richard Stallman]

    There's been a change in window-list that removes available
    functionality:

What you were using was a bug.

     getting the list of windows in canonical order,
    starting with the first window.

When you say "the first window", do you mean the one at the top
left?  If so, (window-list nil nil (frame-first-window)) should
do what you want.  There is no need for a new feature,
and I don't want to add one.

Re: window-list

[Karl Chen]

>>>>> "Luc" == Luc Teirlinck <teirllm@dms.auburn.edu> writes:
    Luc> What about:
    Luc> 
    Luc> (window-list frame minibuf (frame-first-window frame))

Yes, that's what I wanted (didn't know about frame-first-window).
Thanks.  Then I agree, no new feature needed.


-- 
Karl 2004-08-18 13:16

Re: window-list

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
> 
>    I don't recall any discussion about the need for that change, but
>    I guess there was a reason....
> 
> To make the function do what both its docstring and the documentation
> in the Elisp manual claim it does:
> 
>  -- Function: window-list &optional frame minibuf window
>      This function returns a list of the windows on FRAME, starting
>      with WINDOW.  If FRAME is `nil' or omitted, the selected frame is
>      used instead; if WINDOW is `nil' or omitted, the selected window
>      is used instead.
> 
> So I do not believe that there _has_ been a change in documented
> behavior.  The documentation was changed quite a while ago, for
> "compatibility with XEmacs".  (Revision 1.322 to window.c on Nov 19,
> 2000, by Gerd.)  I guess the change must have been discussed back
> then.  The new behavior was never correctly implemented, until
> Richard's change.

Thank you for clarifying that.

> 
> As I already pointed out, unless I am misunderstanding, one can get
> the behavior Karl wants, from Elisp, using:
> 
> (window-list frame minibuf (frame-first-window frame))

Would it be an idea to mention that in the manual?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: window-list

[Richard Stallman]

    > (window-list frame minibuf (frame-first-window frame))

    Would it be an idea to mention that in the manual?

I don't think we need to clutter the manual by documenting erroneous
behavior that has been fixed.  The behavior of the function now agrees
with its documentation, so if anyone sees an incorrect use of it, he
will know how to fix it.

Re: window-list

[Karl Chen]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:
    rms> 
    >> (window-list frame minibuf (frame-first-window frame))
    rms>     Would it be an idea to mention that in the manual?
    rms> 
    rms> I don't think we need to clutter the manual by
    rms> documenting erroneous behavior that has been fixed.  The
    rms> behavior of the function now agrees with its
    rms> documentation, so if anyone sees an incorrect use of it,
    rms> he will know how to fix it.
    rms> 

How about cluttering NEWS then?


-- 
Karl 2004-08-20 14:03

Re: window-list

[Richard Stallman]

    How about cluttering NEWS then?

Ok, I guess.

Re: window-list

[Luc Teirlinck]

Richard Stallman wrote (in response to Karl Chen):
       
       How about cluttering NEWS then?

   Ok, I guess.

Cluttering NEWS with _what_ exactly?  The behavior of `window-list'
_is_ already documented in the NEWS:

    ** The new function `window-list' has been defined

    - Function: window-list &optional FRAME WINDOW MINIBUF

    Return a list of windows on FRAME, starting with WINDOW.  FRAME nil or
    omitted means use the selected frame.  WINDOW nil or omitted means use
    the selected window.  MINIBUF t means include the minibuffer window,
    even if it isn't active.  MINIBUF nil or omitted means include the
    minibuffer window only if it's active.  MINIBUF neither nil nor t
    means never include the minibuffer window.

Sincerely,

Luc.