emacs-devel
[Top][All Lists]
Advanced

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

Re: display-buffer-alist simplifications


From: Stefan Monnier
Subject: Re: display-buffer-alist simplifications
Date: Fri, 12 Aug 2011 22:29:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> (defun display-buffer (&optional buffer action)
>> "Display BUFFER in some window."
>> (let* ((user-action
>> (assq-regexp (buffer-name buffer) display-buffer-alist))
>> (functions (append (car display-buffer-overriding-action)
>> (car user-action)
>> (car action)
> Here the user has only two choices: Either accept the (car action) with
> its alist or use its own (car user-action) with its own alist.

No: the alist passed to the function is built by combining the user's
and the caller's.
The only thing the user's FUNCTION doesn't know is the caller's
FUNCTION, although it can fallback to it by retuning nil.

>> (defun display-buffer-other-window (buffer alist)
>> (let ((pop-up-windows t)
>> (special-display-buffer-names nil)
>> (special-display-regexps nil)
>> (same-window-buffer-names nil)
>> (same-window-regexps nil))
>> (emacs23-display-buffer buffer)))
> IIUC this is the Emacs23 compatible version skillful users can override
> by supplying their own version.

This is a sample function that can be used in
message-mail-other-window to maximize backward compatibility.

> I'm not quite sure how they would indicate such a preference via
> `display-buffer-alist'

Not sure what "such a preference" refers to.

> but apparently the "function that takes a buffer and returns
> a boolean" together with some knowledge about the command that is
> currently executed should allow them to do that.

They can either recognize the buffer name via the regexp, or the
buffer's major-mode (yes, the latter requires a function that takes the
buffer and returns non-nil iff the major-mode is the right one).
I don't think that "knowledge about the command that is currently
executed" is something we want to provide because it's too messy.

> My basic problem with your approach is the following: When we write a
> `display-buffer-near-minibuffer' function that reuses the bottom window,
> we have two choices wrt evening window heights - do it or don't do it.

You're referring to the following point, I think:
  - the display method has to handle everything, there's no common/shared
    postprocessing.
The way I think we would handle it is by making most/all
display-buffer-<foo> function finish by calling
a display-buffer-post-process function, passing it the ALIST.
So the ALIST may include something like (even-window . height) to
specify whether and how to even windows.

> someone who wants the opposite behavior.  And you will propose to
> respect the value of the good old `even-window-heights' option in
> `display-buffer-near-minibuffer'.  Why would I be not surprised?

I don't see any reason why a brand new method such as
display-buffer-near-minibuffer should obey obsolete config vars.

> As a next step suppose Chong wants to adjust the height of the new
> window created by `display-buffer-near-minibuffer' calling, for example,
> `fit-window-to-buffer'.  We'll soon find someone who dislikes this
> behavior and wants `display-buffer' to leave the new height alone.  So
> someone will propose to add a new user option to turn that
> behavior off.

If someone suggest it, it's fine: we can just answer by adding
a `fit-window' parameter in the ALIST to control this behavior.

> And people will continue adding new options as they did with
> special-display-..., same-window-..., display-buffer-reuse-frames, and
> display-buffer-mark-dedicated.

I don't see any reason why that should be the case.

> The `display-buffer-alist' idea was to radically put an end to that.
> This means that such options can be added _exclusively_ via the alist
> and no new variables must be introduced.  And obviously it would have
> prompted users to customize it in order to get the behavior they want.
> But the interaction between options would have been based on a strict
> priority.  Emacs 23 options are not manageable in this regard.

AFAICT my proposal shares the same goal and the same property in
this regard.

> Most of what you propose above is easily available in Emacs 23 via
> `special-display-regexps'.

Nope.

> An application would just temporarily add
> the buffer, the function, and the alist to the head of that and get the
> behavior without setting any arguments.

But then the user can't override it without a lot of effort.
My proposal fixes this problem just as well as yours.

> Is it really worth inventing a new `display-buffer' in order to
> resolve such cosmetic issues?

I don't understand the question.

To get back to my suggestion, I think it's really not that different
from your code.  We can largely provide the same predefined methods (just
that things like the `reuse-window' symbol turns into a function
`display-buffer-reuse-window', forcing the code to be more modular) and
let them handle the same set of arguments and parameters (tho the args
to `reuse-window' need to be turned into named parameters).

Admittedly, you won't be able to do the equivalent of
((reuse-window foo bar) (reuse-window titi toto)) because the args
passed to FUNCTIONs are the same for each FUNCTION, so if a FUNCTION
appears twice both occurrences will behave identically.


        Stefan



reply via email to

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