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

From: martin rudalics <[email-masked]>
Date: Sun, 18 Nov 2018 10:24:56 +0100

> Then maybe better to add such buffers to the end of the prev-buffers list
 > or to the end of the next-buffers list.

We have that option in 'debugger-bury-or-kill'.  Do you mean to
generalize it?

 >>> The second time when the buffer is displayed again in a previous window
 >>> is deterministic.  But the first time it is non-deterministic - it's
 >>> displayed in a random window.  At least, the user can't predict the
 >>> window where it will be displayed - thus the surprise factor.
 >>> With get-mru-window instead get-lru-window the place is more
 >>> deterministic because the user usually remembers which window is mru.
 >>
 >> We can add an action alist entry to get the mru (or better
 >> mru-not-selected) behavior.  A small deal.
 >
 > This would be very nice, thanks in advance.

OK.  What do you want to call it, 'windows-to-examine'?  Shall we make
it a list of function/frame pairs defaulting to

'((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 0))

where nil stands for whatever

(or (window--frame-usable-p (selected-frame))
     (window--frame-usable-p (last-nonminibuffer-frame)))

returns?  Or do you want to control the DEDICATED and NOT-SELECTED
arguments as well?  I hope that 'get-largest-window', 'get-lru-window'
and 'get-mru-window' are 100% compatible wrt their arguments but
haven't verified that yet.

 > I don't understand what an alist entry you mean.  Or you mean adding
 > a new alist entry like (default-window . mru-not-selected)?

For example.  To provide the 'windows-to-examine' sketched above you
wouldn't want to specify an action function too.

martin