Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames

[martin rudalics <rudalics@gmx.at>]

 >> BTW in the version you attached I see
 >> +                     (get-lru-window (or reusable-frames frame) nil t))))
 >>
 >> What's the purpose of 'reusable-frames' here?
 >
 >>From a previous message here is the scenario that I envisioned
 > and have tested:
 >
 >> they have 3 visible frames, one for each monitor, and they want
 >> the lru window to be selected from any of those visible frames
 >
 > They achieve this by including '(reusable-frames . visible) in the
 > alist. That way they can get the same behavior for all visible windows
 > as they would if they had a single monitor and a single frame.

Suppose a user provided a 'reusable-frames' entry and an application now
asks for 'display-buffer-use-least-recent-window'.  The customization
which earlier affected 'display-buffer-reuse-window' only would now
affect the search of a window that does not show BUFFER too.  This would
constitute an incompatible change we simply cannot explain.

We could add a new action alist entry like 'lru-frames'.  Then we could
use that in 'display-buffer-use-some-window' too.  Not really suitable
for Emacs 29 though.

Can't those 3 monitors people use 'display-buffer-use-some-frame' with a
suitable 'frame-predicate' instead?

 > In light of this discussion which patch do we want to go with? The one
 > that calls get-buffer-window internally or the one that does not? Once
 > we have the answer I will summarize what we have discussed here
 > in the comments and send a final patch.

Let's not rush things again.  We deal here with half-baked changes and
should try to put them straight to eliminate collateral effects instead
of adding new ones.

martin