Re: display-buffer-alist simplifications

[Stefan Monnier]

>> Here are the difference I see:

In the mean time I thought of 2 more:
- all the args to the display methods are in the ALIST rather than
  having some in the ALIST and some bundled with the display method.
- the display method has to handle everything, there's no common/shared
  postprocessing.

>> - use functions rather than a finite set of symbols.
> Not really a difference because `display-buffer-alist' provides the
> function specifier.

I know, but what I meant is that everything is handled through the
FUNCTION case.

>>> So when an application sets the argument, people who want the old
>>> behavior are overridden.  This means that such people can use
>>> `message-mail' as before but any of their customizations affecting
>>> `message-mail-other-window' or `message-mail-other-frame' are lost.
>> Yes (unless message-mail-other-window keeps using the old let-binding
>> horror, of course).
> With customization I meant that so far they can make
> `message-mail-other-window' use another frame by setting `pop-up-frames'
> to t.  This won't be possible any more.

Yes, that's what I understood, and I think that's OK.
If we don't like that, we can make display-buffer-other-window obey
pop-up-frames as well.  But such supplemental backward compatibility
should only be added on a case-by-case basis.  And I'd much rather
provide "other-window-prefix" and "other-frame-prefix" commands so that
when people ask for such compatibility we can tell us: here's the new,
better way to do it.


        Stefan