Subject: Re: bug#32825: 27.0.50; Deterministic window management

From: Juri Linkov <[email-masked]>
Date: Sun, 11 Nov 2018 22:13:51 +0200

> Currently we use a window's previous buffers for three things:
>
> (1) For 'switch-to-prev-buffer'.
>
> (2) To find a buffer to display when killing or burying a window's
>     buffer and the window shall be kept.
>
> (3) For finding a window in 'display-buffer-in-previous-window'.
>
> Personally I don't care about (2).  But two things about (1) that
> annoy me in practice are: When the window-local buffer list is
> exhausted I get a buffer from the frame-local or global lists, so I
> often enough get TAGS or other intestines dished in that window and,

Regarding TAGS, I spend much time killing TAGS buffers, but they
quickly reappear in the buffer list like in a whac-a-mole type of game.
Shouldn't such internal types of buffers be named with a leading space
in their buffer names?

> to double my pleasure, indirectly have these enter the window-local
> list.  I'd rather restart with a buffer from the window-local list
> provided that list is "long enough".  That's fuzzy to implement.

You mean a cyclic window-local buffer list?

> And, I get too many irrelevant buffers like temporary ones from the
> window-local list.  OTOH it's just the temporary buffers we want to
> keep there because of (3).  Moreover, when I'm in a window reused by
> *Help* and I want to temporarily switch to that window's previous
> buffer then switching back to the window's next buffer should probably
> get me back to *Help*.  So what I'd like is yet another notion of
> fuzziness that after some time forgets about temporary buffers shown
> in a window in the past, including *Backtrace*.

Maybe the notion of burying should also apply to window-local
buffer list?  So burying a buffer should push it to the end of
window-local buffer list?