[Top][All Lists]
[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?
- Re: display-buffer-alist simplifications, (continued)
Re: display-buffer-alist simplifications, martin rudalics, 2011/07/23
- Re: display-buffer-alist simplifications, Eli Zaretskii, 2011/07/23
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/07/23
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/23
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/07/23
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/24
- Re: display-buffer-alist simplifications,
Chong Yidong <=
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/24
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/24
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/07/24
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/25
- Re: display-buffer-alist simplifications, Štěpán Němec, 2011/07/25
- Re: display-buffer-alist simplifications, Juanma Barranquero, 2011/07/25
- Re: display-buffer-alist simplifications, Tim Cross, 2011/07/25
Re: display-buffer-alist simplifications, Juri Linkov, 2011/07/25
Re: display-buffer-alist simplifications, Stephen J. Turnbull, 2011/07/25
Re: display-buffer-alist simplifications, David Kastrup, 2011/07/26