emacs-devel
[Top][All Lists]
Advanced

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

Re: display-buffer-overriding-action


From: Stefan Monnier
Subject: Re: display-buffer-overriding-action
Date: Tue, 13 Sep 2011 13:59:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> No, the override-action is so the user can dynamically override even
>> his own settings.  E.g. C-x 5 b should override a user's own settings
>> of "same-window" for that buffer (after all, that's why he used C-x 5
>> b rather than C-x b).
>> So it's meant to be let-bound or set temporarily (the "set
>> temporarily" is for the case where we implement a new (prefix) command
>> to bind to keys like C-x 5 or C-x 4).

> This is not very clear.  By "his own settings", do you mean the settings
> in `display-buffer-alist' or `display-buffer-default-action'?  The

Both.

> former is not a problem: C-x 5 b passes an ACTION argument to
> pop-to-buffer, which takes precedence over d-b-alist.

No, the ACTION argument takes precedence over d-b-default-action but not
over d-b-alist.

> If the former, how is d-b-overriding-action supposed to know which way
> to override d-b-alist?

I don't understand the question.

> The display-buffer action functions aren't told what the original
> arguments to display-buffer were, so it can't know whether
> display-buffer was called for `C-x 5 b' or `C-x 4 b', or another
> command entirely.

C-x 5 b would not do

  (display-buffer BUFFER <some-clever-action)
but
  (let ((d-b-overriding-action <some-clever-action>))
    (display-buffer BUFFER))

Admittedly, it would be a change (currently C-x 5 b obeys
special-display-*) and we don't have any experience with such behavior,
but that's the intention behind this variable.

Another is for

   (defun foo-other-frame ()
     (let ((d-b-overriding-action <some-clever-action>))
       (foo)))

where foo-other-frame- does not otherwise have an easy way to change the
ACTION argument passed by `foo' to display-buffer.
       
My own interest is in replacing all those *-other-window and
*-other-frame commands by other-window-prefix and other-frame-prefix.

But I think other than providing the new framework (and making sure, on
the side, that it does provide the flexibility we want), we should not
make other changes to the code (e.g. to try and make use of this new
framework).


        Stefan



reply via email to

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