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

[martin rudalics <rudalics@gmx.at>]

 > Here is the updated patch, but it comes with a question.
 > On review, the reason why I did not include a call to
 > display-buffer-reuse-window (or get-buffer-window)
 > internally is because in my config I have the following
 >
 > (setq display-buffer-base-action
 >        '((display-buffer-reuse-window display-buffer-use-least-recent-window)))

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.

 > I think it is probably correct to have display-buffer-use-least-recent-window
 > try to call display-buffer-reuse-window itself (effectively), however it does
 > seem like it makes display-buffer-use-least-recent-window less composable
 > because it can no longer be used to compose a base action that did not
 > reuse existing windows.

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

 > For example I can imagine that someone might want to display a buffer
 > twice and have the 2nd instance of the buffer pick the least recent window
 > by default. If we use this version of the patch that is no longer possible.

How would the other version handle it?  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?

martin