emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications


From: Chong Yidong
Subject: Re: display-buffer-alist simplifications
Date: Sun, 24 Jul 2011 09:54:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

martin rudalics <address@hidden> writes:

> (setq
>  display-buffer-alist
>  '((((regexp . ".*"))
>     (reuse-window other same)
>     (reuse-window-even-sizes . t)
>     (reuse-window other other)
>     (reuse-window-even-sizes . nil))))

This is not clean.  The specifiers interact with one another, and their
ordering affects the behavior of other specifiers.  Semantically it is
even more complicated than font-lock-keywords---which isn't even
user-customizable.

>> display-buffer-alist is trying to serve two purposes: "merging"
>> specifiers passed to display-buffer, and "overriding" them completely.
>> That makes it very complicated to use/understand.
>
> Merging should be the rule.  Overriding should happen only in a few
> cases, when a user is completely dissatisfied with the application's
> specifier.  In practice, this means that we can either tell a user on
> Emacs-devel something like "this should get fixed by the application
> soon, meanwhile try to override this by ..." or "the behavior you want
> is very unusual so could you please try overriding it by ...".

Getting this to work right seems complicated.  If you can provide a
*specific* example of how you intend merging to work, maybe it will make
it clearer for me.

For example, suppose I want Emacs to (i) always avoid displaying in the
current window first, even if the display-buffer specifier says so; (ii)
when trying to reuse a window that already has the desired buffer on the
current frame, also try looking in other frames at the same time; and
(iii) if all other specifiers fail, fall back on using the current
window.  How is that done?

>> Why not let display-buffer-alist exclusively perform the "override"
>> case---i.e. let it take precedence over display-buffer's argument
>> specifiers?
>
> Impossible.  The first consequence of this would be applications
> rebinding `display-buffer-alist' to nil around `display-buffer' calls.
> How would you implement `info-other-window' or `find-file-other-frame'
> when the user has a `display-buffer-alist' entry for *Info* or the file
> in question?

Isn't that what you introduced labels for?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]