[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: Thu, 15 Nov 2018 10:12:46 +0100

> 'display-buffer-in-previous-window' searches the buffer in the
> prev-buffers list that 'switch-to-prev-buffer' might want to skip
> (I still doubt this need).

The need to skip or the need to search?

> I proposed to generalize display-buffer-in-previous-window
> to avoid duplicating code like in debug.el that uses
> debugger-previous-window, debugger-pre-previous-window,
> debugger-previous-window-height because the same feature
> is needed in other packages like edebug.el.
> The same feature is needed also for next-error to display hits
> from different buffers in the same window.

When a user can always make a new window there is indeed no problem:
place or reuse the window below the selected window or on the bottom
of the frame.  Both approaches are sufficiently deterministic in their
choice of a window.

But as soon as a window must be reused and the selected one is at the
bottom of the frame, it can become quite difficult to assure that a
buffer shows up in a deterministic location.  This eventually gave
raise to the idea of introducing 'display-buffer-in-previous-window'
(together with the fact that a window's previous buffers then became
easily available via 'window-prev-buffers').

But 'display-buffer-in-previous-window' works only when the buffer is
(1) kept alive while not being displayed and (2) is kept on the list
of a window's previous buffers.  We could add the _names_ of buffers
previously shown to 'window-prev-buffers' but that would not allow for
auto-removing entries when a buffer gets killed and also fail when
buffers are renamed.  So generalizing that function might be

> Or better to obviate the need in all this complex special handling
> simply by removing the get-lru-window rule in the default action,
> thus replacing it with get-mru-window.

When people work with two windows simultaneously, the mru one is
usually the "other" window they work with, maybe showing the same
buffer at a different location.  I think it would be a bad idea to
punish such users by reusing the other window for showing some
temporary buffer instead.


reply via email to

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