[Top][All Lists]

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

bug#32825: 27.0.50; Deterministic window management

From: martin rudalics
Subject: bug#32825: 27.0.50; Deterministic window management
Date: Wed, 21 Nov 2018 09:19:48 +0100

> I imagine a list of prev/next-buffers as the tab-bar:
> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E]
> prev-buffers          current-buffer      next-buffers
> Using switch-to-buffer adds a new buffer after the current "tab", e.g.
> [buffer-A] [buffer-B] [buffer-C] [new-buffer] [buffer-D] [buffer-E]
> prev-buffers                  current-buffer           next-buffers

So far the buffer shown by a window does not appear in its lists of
previous or next buffers.

> But displaying a temporary buffer could add a "tab" to the end of the
> tab-bar, this means at the end of the list of next-buffers:
> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
> prev-buffers                                         current-buffer

The problem with this approach is as follows: The list of next buffers
is usually empty because it contains only the buffers visited while
navigating the list of previous buffers backwards in time.  It's main
purpose is to revert any overshooting during such navigation.  But
this means that when you add your temporary buffer to the (usually
empty) list of next buffers, overshooting while reverting the
overshooting will get you to that temporary buffer immediately.

In your example I would first show buffer-C then overshoot and show
buffer-B.  Reverting that gets me to buffer-C and overshooting once
more will get me new-buffer immediately (because buffer-D and buffer-E
typically do not exist).

> After exiting from this temporary buffer, it could be kept in the
> list of next-buffers:
> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
> prev-buffers          current-buffer                    next-buffers
> Then returning to prev-buffers (e.g. with kill-buffer) will not visit
> this temporary buffer.  But display-buffer-reuse-window could look for
> a previously displayed buffer in the list of next buffers.

The main purpose of a window's list of next buffers is that of undoing
a 'switch-to-prev-buffer' step.  I have no idea which consequences
your proposal could have apart from the one I sketched above.  I'm
already no great friend of

     If there is no recent invocation of `switch-to-prev-buffer' that
     can be undone, this function tries to show a buffer from the
     buffer list of the frame WINDOW appears on ...

but this comes from an attempt to model buffer switching like 'undo'


reply via email to

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