Re: display-buffer-alist simplifications

[martin rudalics]

> If it hurts don't do that: the way my proposal works indeed does not
> lend itself to the kind of decomposition you've used in the current code.
>
> 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?

>> If `user-action' specifies
>> '(display-buffer-pop-up-window . ((window . largest)))
>> `display-buffer' will try to split the lru window.
>
> That indicates a name conflict, i.e. a misfeature in your choice of
> parameter names.

IIRC it was Juri's idea to unify keys this way.  Good to know that it's
a misfeature.

> Just like different programming languages end up favoring different
> coding styles (even though most programming languages are fundamentally
> very similar), my buffer-display-alist is sufficiently different from
> yours that it will favor a different kind of decomposition than the
> one you've currently implemented.

Already in Emacs 23 we had three basic functions to find a window for
`display-buffer': `window--reuse-window', `window--pop-up-window' and
`window--pop-up-frame'.  These are the basic building blocks and
whatever we want to do on top will always boil down to calling some
variant of these.

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

Bold ;-)

martin