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

[martin rudalics]

>> 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