Re: display-buffer-alist simplifications

[Stefan Monnier]

>> Until now there is no caller out there that specifies "I want to reuse
>> an existing window and I want it to be the LRU", and neither is there
>> a user out there that has a config that says "buffers names TOTO should
>> be displayed in an existing window and should use the largest window".
>> So it's not a real problem.

> So when we write a function `display-buffer-near-minibuffer' and want to
> reuse the bottom-most window we can't decompose?

I don't know what you mean by "decompose".  I suspect you're referring
to the way your current display-buffer-alist provides very fine-grained
building blocks that are combined in display-buffer-alist specifiers.
If so, indeed, my design does not make such decomposition easy.
But I don't think it's a problem: the decomposition can be done in the
Elisp code instead (i.e. display-buffer-near-minibuffer can call some
display-buffer-reuse-foo function).

>> - the functionality of Emacs-23 (i.e. mostly same-frame, same-window,
>> other-window, other-frame, dedicated-or-not, existing-window) so as to
>> be able to mark the various old config vars as obsolete.
> Without offering anything people can customize instead but a single
> option called `display-buffer-alist' to choose one of these functions?

Almost.  Actually, I think there are 2 defcustoms: display-buffer-alist
and display-buffer-default-rule.  The default-rule will replace things
like pop-up-frames/pop-up-windows/display-buffer-reuse-frames, while
display-buffer-alist will replace things like same-window-* and
special-display-*.

Juri writes:
> Or with Stefan's design without decomposition
> these actions could be specified as:
> '(display-buffer-reuse-lru-window . ())
> '(display-buffer-reuse-largest-window . ())

No, since all these params belong to display-buffer-alist, the
"display-buffer-" prefix would be unnecessary.


        Stefan