[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#21305: closed (25.0.50; `get-buffer-window-list' d

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#21305: closed (25.0.50; `get-buffer-window-list' doc - what order?)
Date: Fri, 21 Aug 2015 15:22:02 +0000

Your message dated Fri, 21 Aug 2015 18:21:18 +0300
with message-id <address@hidden>
and subject line Re: bug#21305: 25.0.50; `get-buffer-window-list' doc - what 
has caused the debbugs.gnu.org bug report #21305,
regarding 25.0.50; `get-buffer-window-list' doc - what order?
to be marked as done.

(If you believe you have received this mail in error, please contact

21305: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21305
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 25.0.50; `get-buffer-window-list' doc - what order? Date: Thu, 20 Aug 2015 10:49:26 -0700 (PDT)
The doc string says: "Windows are scanned starting with the selected
window."  What does that mean?  Scanned?  How so?  In what order are
they scanned (besides starting with selected)?  And how is the scanning

What I would really like to know should have little or nothing to do
with "scanning".  It is what order the list is in.  Details of how the
function computes the list are not so important, but if you have to tell
us that in order to specify the resulting order, so be it.

Please update both the doc string and (elisp) `Buffers and Windows'
to tell us what order the list is in.

In GNU Emacs (i686-pc-mingw32)
 of 2015-07-31 on LEG570
Bzr revision: 8d332aeccab2208e6c6bd434738565e6abf12043
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

--- End Message ---
--- Begin Message --- Subject: Re: bug#21305: 25.0.50; `get-buffer-window-list' doc - what order? Date: Fri, 21 Aug 2015 18:21:18 +0300
> Date: Fri, 21 Aug 2015 08:08:25 -0700 (PDT)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> > > > The order is unspecified, which means the caller should not
> > > > depend on it.  I don't think there's anything wrong with that;
> > > > do you?
> > >
> > > Well, it's certainly the prerogative of designers to decide that
> > > the order is undefined and that users cannot depend on it.  In
> > > that case, you can close the bug now.
> > >
> > > But as one user I'm disappointed.  I was hoping for a usable
> > > window order.
> > 
> > It's the order of traversing the window tree depth-first (as
> > described in the ELisp manual under "Cyclic Window Ordering").
> If so, then the order is not undefined.

I didn't say "undefined", I said "unspecified".

> > I don't see how saying that would be of any help to users of this
> > function.
> Well, it apparently won't help me in my quest for a chronological
> ordering of windows for the same buffer by access time.
> But I think it would be helpful to tell users that the order is
> the same as that described in `Cyclic Window Ordering'.

What can the users do with that information?  (It is already in the
ELisp manual; I'm talking about the doc string here.)

> > Describing the order would require a non-trivial amount of text, so
> > without a good reason, I don't think we should add it.
> How is it more difficult than saying that the order is the same as
> that specified in `Cyclic Window Ordering', and xreffing that node?

I consider references to the manual in doc strings a bad habit.

I'm closing the bug.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]