Re: display-buffer-alist simplifications

[martin rudalics]

> The topic at hand is whether `display-buffer-alist' should "merge" into
> the display specifier supplied to `display-buffer'.  Let's put aside the
> question of whether the Emacs 23 system is or is not complicated.

The question whether and how to merge such a specifier is central to the
question whether we should change the semantics of the not-this-window
argument of `display-buffer' at all.  If we prefer to not do that, then
I should be able to provide a working version of `display-buffer' from
last autumn which might be quite usable as fallback.  Since most people
do find `display-buffer-alist' much too complicated and Stefan is
apparently opposed to almost all new features it provides, we should
seriously consider reverting the changes introduced by buffer display
specifiers.  In this context it makes also sense to discuss whether the
Emacs 23 system is or is not complicated.

> So, IIUC, this converts the same-window specifier
>
>   ((reuse-window same nil nil))
>
> to
>
>   ((reuse-window other nil 0)
>    (reuse-window same nil nil)
>    (reuse-window same))
>
> Right?

Although I'd formulate it the other way round I can live with your
interpretation.

> This form of "merging" can be eliminated by providing a
> `display-buffer-fallback-alist', removing the need for (override . t)
> and one source of unwanted interaction between specifiers.

First of all you would have to give me some idea of what
`display-buffer-fallback-alist' should look like.  Should it be
constructed from the same associations as `display-buffer-alist'?  If
so, then why do you think it's better to pay for removing the (override
. t) entries (which should be fairly rare BTW) with another variable and
a doc-string that would either have to refer to that of
`display-buffer-alist' or replicate most of the latter.

> Here is the basic point.  You're arguing for a buffer display specifier
> syntax that consists of interacting elements, because this syntax allows
> `display-buffer-alist' to "merge with" or "influence" the specifiers
> supplied to `display-buffer'.

Yes.  The design is still that of Emacs 23 where the `not-this-window'
argument gets interpreted by `display-buffer' as (1) reuse another
window with the value of `even-window-heights' merged in, (2) pop up a
new window with the values of `split-window-preferred-function' merged
in and that of `split-...-threshold' influencing it, or (3) pop up a
frame with the value of `pop-up-frame-alist' merged in.

> Having gone through these examples, I am
> convinced that the cost of this design outweighs the benefits.

Can you tell me what you mean by "cost of the design" and how exactly
you want to avoid that cost.  You cannot avoid merging specifiers unless
you duplicate each and every component like `even-sizes' in each and
every specifier.  In the latter case the cost of maintaining an option
like `display-buffer-alist' would clearly outweigh any benefits gained
by making the design less expensive.

> It is far more important to use a syntax that is easy to understand.
> If I have a list of specifiers
>
>   (A B C ...)
>
> that should mean "try A; if that fails, try B; if that fails, try C".

Nothing in the current design prevents you from writing precisely that.

> And not a situation where certain B's are not things to try, but instead
> are tags that modify how A behaves, or tags that say how to merge this
> list with the argument to `display-buffer', etc.  This kind of
> pseudo-programming language is not a good fit to the Emacs concept of
> customizable options; the traditional way of providing customizable
> programming logic is with hooks and abnormal hooks.

It's completely up to the users whether they want that or not.  Users
who don't want a certain B to modify how A behaves can include in A all
necessary ingredients to make sure that B never affects the behavior of
A.  But why should other users who do want B to affect the behavior of A
pay for that by being forced to replicate all these specifiers in A?

> The point is that `info-other-window' can call display-buffer as
>
>   (display-buffer buf specifiers 'info-other-window)
>
> so the user could override this with
>
>   (setq display-buffer-alist
>         '((info-other-window replacement-spec)))
>
> This obviates the need to provide the specifier merging functionality,
> without forcing Lisp code like `info-other-window' to bind
> display-buffer-alist to nil.

Sigh.  You wanted the specifiers of `display-buffer-alist' to always
override those provided by the application.  If a user's
`display-buffer-alist' contains a regexp entry for *info* buffers
telling to display them always in the same window, the label passed by
`info-other-window' won't have any effect and the buffer will be shown
in the same window.  So the user, in addition, has to provide a
`display-buffer-alist' entry based on the `info-other-window' label
which does nothing but replicate what is said in the argument, namely
"yes, please do display the buffer in another window".  Which means that
users who dare to specify a regexp entry for `display-buffer-alist' also
have to specify an entry for each and every `display-buffer' call with
an application provided argument.


Now shouldn't we rather back out all buffer display changes I've applied
recently and revert to using the old Emacs 23 options?  I could easily
incorporate the changes Stefan mentioned earlier and shortly sketched in

http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00461.html

and we'd forget about the whole new semantics of the second argument of
`display-buffer' and more sophisticated ways to tweak `display-buffer'.
Eventually somebody could quietly look into this and apply whatever
people find more suitable and you could quietly go on with the pretest.

martin, who begins feeling to weak to delve into this subject again.