Re: display-buffer-alist simplifications

[Stefan Monnier]

>> What problems do you guys (fore)see with such a setup?
> Let's see how such a setup serves some specific test-cases:
> 1. The user should be able to specify whether to display the buffer
> in the same window or in another window and which window
> to select after displaying the buffer in another window.

Hmm... please use your words carefully.  I recommend you use "user" for
the guy who sets up buffer-display-alist (via Customize) and "caller" for
the guys who write the code that calls display-buffer.

> Currently these differences are encoded in function names:

>   `switch-to-buffer' - display buffer in the selected window
>   `pop-to-buffer' - display buffer and select its window
>   `display-buffer' - display buffer, but don't select its window

pop-to-buffer just calls display-buffer and then selects the chosen
window, so it's can be ignored.

switch-to-buffer would either use set-window-buffer (and circumvent the
whole display-buffer business) or call pop-to-buffer with
a '(display-buffer-same-window) RULE argument, which can then be
overridden by buffer-display-alist.

> and they are used quite inconsistently in applications.

And there's not much we can do about it, other than try and provide good
new functionality to encourage coders to do it better in the future.

> For instance, to display the "*vc-diff*" buffer,
> `vc-diff-internal' calls (pop-to-buffer "*vc-diff*"),
> but `vc-annotate-show-diff-revision-at-line-internal'
> calls (switch-to-buffer "*vc-diff*").

> How the user can override these application defaults?

All those cases can be overridden by buffer-display-alist.

> To display the "*vc-diff*" buffer in the selected window
> (like `switch-to-buffer'):

>   (setq display-buffer-alist '(
>     ("*vc-diff*" display-buffer-same-window)))

> To display the "*vc-diff*" buffer and not select its window:

>   (setq display-buffer-alist '(
>     ("*vc-diff*" display-buffer-other-window)))

Ah, so your point is that the user should also have control over the
window selection? I think this is outside the scope of the current
design (changing the selected window returned by switch-to-buffer,
pop-to-buffer, and display-buffer would break too much code).

So the same-window vs other-window controls where the buffer is
displayed but not which window ends up selected in the end.

> 2. How the user can override the global defaults?

> For instance, I want to display the *Help* buffer in the selected window.
> But when it's already displayed in another window, then prefer reusing
> another window (because otherwise two windows will be displayed with the
> same buffer).  And not reuse a window on another frame.

> Should I write a new function and use it like:

>   (setq display-buffer-alist '(
>     ("*Help*" display-buffer-other-window-same-frame-or-same-window)))

Yes, I think that would be the answer.

> Or provide additional arguments to the predefined functions like:

>   (setq display-buffer-alist '(
>     ("*Help*" display-buffer-same-window reuse-other-window-same-frame)))

> Or

>   (setq display-buffer-alist '(
>     ("*Help*" display-buffer-same-window (reuse-window . same-frame))))

We could provide a fancy-display.el package defining a magical
display-buffer-according-to-specifiers which would interpret its
parameters in a similar way to what is now done in Martin's
buffer-display-alist.

> 3. How applications can override the global default?

> For instance, what to do to fit the command `info-other-window':

>   (defun info-other-window (&optional file-or-node)
>     "Like `info' but show the Info buffer in another window."
>     (interactive (if current-prefix-arg
>                      (list (read-file-name "Info file name: " nil nil t))))
>     (let (same-window-buffer-names same-window-regexps (pop-up-windows t))
>       (info file-or-node)))

> into the new setup?

This question is orthogonal to the current debate about how to
streamline buffer-display-alist, I think.  But I think the answer would
be to provide an `info-internal' function which takes a DISPLAY-RULE
param and then rewrite `info' and `info-other-window' in terms of that
new function.

I know this won't satisfy everyone, but let-binding as is done above has
too many problems of its own.  Maybe we could have a new
display-buffer-default-rule variable (not a user option) such that
display-buffer uses this variable when its RULE arg is nil, so
info-other-window could do

  (let ((display-buffer-default-rule '(display-buffer-other-window)))
    (info ...))

A related issue: I tend to dislike the *-other-(frame|window) commands
and would rather have C-x 4 and C-x 5 as prefix commands that modify the
way the subsequent command works.  Not sure how best to get this behavior.


        Stefan