[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 17:32:05 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
martin rudalics <address@hidden> writes:
>> This is not clean. The specifiers interact with one another, and
>> their ordering affects the behavior of other specifiers.
>
> The ordering is important, yes. But the ordering is fully controlled
> by the user.
>
> The semantics of `display-buffer-alist' are certainly cleaner than the
> semantics of Emacs 23 options. With `display-buffer-alist' you only
> specify what _shall_ be done. You don't care about what shall be
> avoided. OTOH Emacs 23 options provide a mixture of what should be
> done and what should be avoided.
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.
> Tell me what's missing in the form
>
> (setq
> display-buffer-alist
> '((((regexp . ".*"))
> (reuse-window other nil 0)
> (override . t)
> (reuse-window same))))
>
> for a call like
>
> (display-buffer "*scratch*" 'same-window)
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? 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.
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'. Having gone through these examples, I am
convinced that the cost of this design outweighs the benefits.
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".
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.
>>> 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?
>
> Labels should be used when the application proposes to do something
> special for a specific command or function but the user wants it to do
> something different.
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.
- 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, 2011/07/24
- 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 <=
- 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
- Re: display-buffer-alist simplifications, Stephen J. Turnbull, 2011/07/26
- Re: display-buffer-alist simplifications, David Kastrup, 2011/07/26
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/07/26