window-next-buffers

window-next-buffers

[Chong Yidong]

IIUC, the functions window-next-buffers and set-window-next-buffers (and
the corresponding next_buffers slot) exist for navigating "forward" in
the window history list, via switch-to-next-buffer, after doing
switch-to-prev-buffer.

Maintaining separate prev-history and next-history lists is not very
Emacs-y.  Why isn't this a ring?

Re: window-next-buffers

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> IIUC, the functions window-next-buffers and set-window-next-buffers (and
> the corresponding next_buffers slot) exist for navigating "forward" in
> the window history list, via switch-to-next-buffer, after doing
> switch-to-prev-buffer.
>
> Maintaining separate prev-history and next-history lists is not very
> Emacs-y.  Why isn't this a ring?

On second thought, never mind.  We don't generally use rings for
history.  I do find the window-next-buffers stuff a bit weird, somehow,
but it's not important.

Re: window-next-buffers

[martin rudalics]

 > I do find the window-next-buffers stuff a bit weird, somehow,
 > but it's not important.

A window's next buffers are only needed while navigating back- and
forwards through that window's buffers.  They are killed by
`set-window-buffer' (more precisely by `record-window-buffer').  A
window's previous buffers are persistent.

martin

Re: window-next-buffers

[martin rudalics]

 > IIUC, the functions window-next-buffers and set-window-next-buffers (and
 > the corresponding next_buffers slot) exist for navigating "forward" in
 > the window history list, via switch-to-next-buffer, after doing
 > switch-to-prev-buffer.
 >
 > Maintaining separate prev-history and next-history lists is not very
 > Emacs-y.  Why isn't this a ring?

Because `window-previous-buffers' returns a list of <buffer window-start
pos> triples where the latter two are markers and `window-next-buffers'
a plain list of buffers.  Maintaining markers is expensive, so I wanted
to reduce the overhead for the next buffers part of the list.

martin

Re: window-next-buffers

[Juri Linkov]

>> Maintaining separate prev-history and next-history lists is not very
>> Emacs-y.  Why isn't this a ring?
>
> Because `window-previous-buffers' returns a list of <buffer window-start
> pos> triples where the latter two are markers and `window-next-buffers'
> a plain list of buffers.  Maintaining markers is expensive, so I wanted
> to reduce the overhead for the next buffers part of the list.

This sounds like an overly optimization.  But actually I can't find
a case where `next-buffer' would fail to get information about markers.
Is this because information about markers of next buffers is retrieved
from `window-prev-buffers'?

> > I do find the window-next-buffers stuff a bit weird, somehow,
> > but it's not important.
>
> A window's next buffers are only needed while navigating back- and
> forwards through that window's buffers.  They are killed by
> `set-window-buffer' (more precisely by `record-window-buffer').  A
> window's previous buffers are persistent.

Isn't better to push a new window to the top of the list of next buffers
to not lose information about the rest of next buffers?

Re: window-next-buffers

[martin rudalics]

 > This sounds like an overly optimization.  But actually I can't find
 > a case where `next-buffer' would fail to get information about markers.
 > Is this because information about markers of next buffers is retrieved
 > from `window-prev-buffers'?

Yes.  In `switch-to-next-buffer'

(assq buffer (window-prev-buffers window))

provides this information.  `window-next-buffers' is exclusively used
for buffer navigation within a window.  `window-prev-buffers' is used in
other occasions like `quit-window' where I don't care about a window's
next buffers.

 > Isn't better to push a new window to the top of the list of next buffers
 > to not lose information about the rest of next buffers?

Can you elaborate what you mean here?  A new window has neither previous
nor next buffers.

martin

Re: window-next-buffers

[Juri Linkov]

>> This sounds like an overly optimization.  But actually I can't find
>> a case where `next-buffer' would fail to get information about markers.
>> Is this because information about markers of next buffers is retrieved
>> from `window-prev-buffers'?
>
> Yes.  In `switch-to-next-buffer'
>
> (assq buffer (window-prev-buffers window))
>
> provides this information.  `window-next-buffers' is exclusively used
> for buffer navigation within a window.  `window-prev-buffers' is used in
> other occasions like `quit-window' where I don't care about a window's
> next buffers.

IIUC this means that a set of next-buffers is a subset of prev-buffers.

>> Isn't better to push a new window to the top of the list of next buffers
>> to not lose information about the rest of next buffers?
>
> Can you elaborate what you mean here?  A new window has neither previous
> nor next buffers.

Sorry, I meant "a new buffer" (displayed in the selected window
by `set-window-buffer').

Re: window-next-buffers

[martin rudalics]

 > IIUC this means that a set of next-buffers is a subset of prev-buffers.

Hopefully.

 > Sorry, I meant "a new buffer" (displayed in the selected window
 > by `set-window-buffer').

You mean that `set-window-buffer` should not throw away a window's next
buffers?  Let's reconsider this when we encounter a real problem with
the present implementation.

martin

Re: window-next-buffers

[Stephen J. Turnbull]

Juri Linkov writes:

 > IIUC this means that a set of next-buffers is a subset of
 > prev-buffers.

Actually, I suspect it means that Yidong was right when he suggested a
ring.  Butnevermind....

Re: window-next-buffers

[Chong Yidong]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Juri Linkov writes:
>
>  > IIUC this means that a set of next-buffers is a subset of
>  > prev-buffers.
>
> Actually, I suspect it means that Yidong was right when he suggested a
> ring.  Butnevermind....

No, I was wrong: a ring isn't a good fit for the design, in which
`switch-to-prev-buffer' (i) switches to the previous buffers displayed
in the buffer, and (ii) after successive `switch-to-prev-buffer's reach
the end of that list, the command moves on to other buffers in the
buffer list which the window hadn't visited before.  If we used a ring,
we'd never hit the end, so we'd never move on to (ii).

But I think the next-buffers list should be considered an internal
detail (i.e. internal to the workings of next-buffer/previous-buffer),
and shouldn't be documented in the Lisp manual.

Re: window-next-buffers

[Juri Linkov]

>> Actually, I suspect it means that Yidong was right when he suggested a
>> ring.  Butnevermind....
>
> No, I was wrong: a ring isn't a good fit for the design, in which
> `switch-to-prev-buffer' (i) switches to the previous buffers displayed
> in the buffer, and (ii) after successive `switch-to-prev-buffer's reach
> the end of that list, the command moves on to other buffers in the
> buffer list which the window hadn't visited before.  If we used a ring,
> we'd never hit the end, so we'd never move on to (ii).

Then we need just one list of buffers (visited in the window)
and the pointer referencing the currently displayed buffer
(or a numeric index of the position of the currently displayed
buffer in the list of visited buffers).

Re: window-next-buffers

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> No, I was wrong: a ring isn't a good fit for the design, in which
>> `switch-to-prev-buffer' (i) switches to the previous buffers displayed
>> in the buffer, and (ii) after successive `switch-to-prev-buffer's reach
>> the end of that list, the command moves on to other buffers in the
>> buffer list which the window hadn't visited before.  If we used a ring,
>> we'd never hit the end, so we'd never move on to (ii).
>
> Then we need just one list of buffers (visited in the window)
> and the pointer referencing the currently displayed buffer
> (or a numeric index of the position of the currently displayed
> buffer in the list of visited buffers).

Yes, that would be far simpler.

Re: window-next-buffers

[martin rudalics]

 > Then we need just one list of buffers (visited in the window)
 > and the pointer referencing the currently displayed buffer
 > (or a numeric index of the position of the currently displayed
 > buffer in the list of visited buffers).

A window's previous buffers are perused as follows:

(1) For navigating the buffers shown in a window.  This calls
     `switch-to-prev-buffer' with BURY-OR-KILL nil and preferably does
     not show a buffer from the window's next buffers.

(2) For burying or killing the buffer shown in a window.  This may call
     `switch-to-prev-buffer' with BURY-OR-KILL non-nil and can show a
     buffer from window's next buffers.

(3) For quitting a window.  This works on the window's previous buffers
     directly and can show a buffer from window's next buffers.

So any optimization for (1) must make sure that operations (2) and (3)
are not harmed.  In addition you will have to do the proper action for
`set-window-buffer'.

And the most annoying problem, namely that a buffer on one of these
lists gets killed while I can't access these lists because they are
hidden by a window excursion, must be handled too (maybe directly in
`set-window-configuration').

martin