Re: display-buffer-alist simplifications

[Stefan Monnier]

> Suppose `display-buffer-overriding-action' specifies as action to reuse
> a window and an alist element to use the lru window like
>
> '(display-buffer-reuse-window . ((window . lru)))
>
> and `user-action' specifies as action to reuse a window and as alist
> element to use the largest window like
>
> '(display-buffer-reuse-window . ((window . largest)))

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.

> If the lru window cannot be reused, `display-buffer' will nevertheless
> try twice to use it and never try to use the largest window.

The double-call is indeed a bit ugly, so we could remove duplicates
before running the hook.

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

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.

We should focus at this point on providing:
- 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.
- the new experimental side-window feature.
- nothing more.

And leave the more refined functionality to Emacs-24.2, so we have time
to experiment with it to see what fits well in this system.

To me the main purpose of the change is to provide the new framework so
we can obsolete the old vars (mostly because they suffer from the
problem of being both custom-vars and vars modified by packages via setq
and via let).  This is a long-standing problem and since it touches vars
used by many Elisp packages it's a long-term change and it's important
to make the old stuff obsolete as soon as possible (i.e. 24.1).

The introduction of more refined specifications of behavior is secondary
and given the timeline, I'd rather postpone it to Emacs-24.2.


        Stefan