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

[Tom Gillespie]

> That's why 'display-buffer-use-least-recent-window' will never succeed
> to become a good citizen in the department of buffer display functions.
> The former will not bump the use time and if the window used by
> 'display-buffer-reuse-window' happens to be the LRU one,
> 'display-buffer-use-least-recent-window' may use it for displaying the
> next buffer.  I tried to convince Lars that this is the basic problem of
> his approach but he didn't listen.  If you try with a 'bump-use-time'
> action alist entry you will see that it works.

In testing I do indeed see the issue where display-buffer-reuse-window
does not bump the use time and thus the reused window which should
have been bumped remains the least recently used and is thus select
for the next buffer when it should not. I can also see, but have not tested
that bump-use-time in the action list would solve it.

> Or, for example, a window that previously displayed the buffer.

Yep, that one would be quite desirable if it could be achieved.

> How would the other version handle it?

The version that calls get-buffer-window internally reuses the window that
currently contains the buffer making no apparent change to the user.

The version that does NOT call get-buffer-widnow internally displays the
buffer in the least recently used window (which in principle might be the
buffer that it is already displayed in). Having played with it a bit, the
behavior is rather confusing and probably undesirable.

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

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.

Best,
Tom