bug#70949: display-buffer-choose-some-window

[Juri Linkov]

> +The above describes the behavior when @code{some-window} @var{alist}
> +entry is @code{lru} or @code{nil} which is the default.  But when,
> +for example, @code{display-buffer-base-action} is customized to
> +@w{@code{(nil . ((some-window . mru)))}}, then the value @code{mru}
> +means that this function will prefer the most recently used window
> +that is useful to display several buffers in the same window
> +in a layout with more than two windows.
>
> This is ambiguous - we should emphasize that these buffers are not
> displayed at the same time.  I'd write something like the following:
>
>   The default behavior might become irritating when 'display-buffer' is
>   used to display a number of related buffers in a row.
>
>   Consider a configuration of two or more windows where a user wants to
>   consult, in a non-selected window, one after the other, the results of a
>   query spread among several buffers.  With the 'lru' strategy, Emacs
>   might continuously choose another window because the least recently used
>   window changes with every call of 'display-buffer-use-some-window'.
>   With the 'mru' strategy, the window chosen would always remain the same,
>   resulting in a less confusing user experience.
>
> If I got it right ...

Not quite right.  It's not about a less confusing user experience.
Here is what the OP wrote for this request:

    I'd rather have file results remain in just one window so that I can use
    other buffers while still viewing search results.

Probably here would be better to say not "other buffers", but "other windows".