Subject: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes'

From: martin rudalics <[email-masked]>
Date: Mon, 13 Aug 2012 09:13:01 +0200

>> Changing `special-display-popup-frame' for >= 24.2 would not
 >> affect its behavior with < 24.2.
 >
 > Fair enough.  I could provide a separate solution for >= 24.2.

For > 24.2 (since yesterday).

 > Agreed.  And I'd be glad to learn how.
 >
 > Perhaps I will provide a separate 24.2+ solution, once we have 24.2.  By that
 > time, based on past experience, it's quite possible that Emacs Dev will have
 > changed things in this area once again - perhaps even radically (again).  But
 > I'm certainly open to finding a solution that does not require redefining
 > `special-display-popup-frame'.
 >
 > However:
 >
 > 1. `display-buffer-base-action' is a user option.  Users can set it to anything,
 > including things that do not do what my redefinition of `s-d-p-f' does, which is
 > to invoke `fit-frame'.  Advising me to customize `display-buffer-base-action'
 > does not speak to providing such functionality in a library for other users.

I said that "customizing `display-buffer-base-action' should be all you
want" because I didn't know that you want to provide that "functionality
in a library for other users'.  In such case you probably want to write
some function derived from your advised, redefined
`special-display-popup-frame', include it in that library and tell
people to call that function by customizing their `display-buffer-alist'
appropriately.

 > 2. I do not yet understand `display-buffer-base-action' enough to know _how_ it
 > might be changed to DTRT here. [*]
 >
 > 3. Wrt #2, in particular, redefining `s-d-p-f' affects only those places in
 > Emacs that call `s-d-p-f', in particular, special-display stuff.  IIUC,
 > `display-buffer-base-action' is general and affects _all_ calls (and only calls)
 > to `display-buffer'.  How to make it affect only what `s-d-p-f' affects?
 >
 > 4. Wrt #2 & #3: Please let me know precisely how you think I could, now (e.g.,
 > for recent Emacs 24 builds plus your code, which I hope you will merge soon),
 > use `display-buffer-base-action' to get the effect of my redefinition of
 > `s-d-p-f'.
 >
 > I'm open to your suggestion, but so far it is not concrete enough for me to see
 > how `display-buffer-base-action' might replace redefining `s-d-p-f', even for
 > Emacs >= 24.2.  What is no doubt obvious to you is not at all clear to me.

It's not obvious to me and I have only a rudimentary solution where I
set `display-buffer-base-action' to a function that always splits the
selected window.  And I do the remaining tweaks by customizing
`display-buffer-alist' in some rudimentary manner too.  As long as we
don't have any feedback from users who start experimenting with this,
there won't be much progress indeed.  In particular if they insist on
tweaking the behavior of `special-display-popup-frame' instead ...

 > [*] FWIW, the `display-buffer-base-action' doc string is not very helpful:
 >
 >  "It should be a cons cell (FUNCTION . ALIST), where FUNCTION is a
 >   function or a list of functions.  Each function should accept two
 >   arguments: a buffer to display and an alist similar to ALIST."
 >
 > What does "similar" to ALIST mean here?  Plus, all the doc tells us is the
 > _form_ of the option value, not what the value means or how it is used.  Yes, it
 > sends us off to the doc for `display-buffer', but that is a labyrinthine jungle.

It looks slightly circular indeed.  But I believe that you should be
able to easily digest the two alist values that currently do have a
special meaning (`inhibit-same-window' and `reusable-frames').  The main
advantage of ALIST is that in your library you can call `display-buffer'
with some special-purpose alist elements and have the function specified
via `display-buffer-alist' recognize these values.

This means that you can get any special behavior when and where you (or
your users) want it, while providing standard behavior for those who do
not.  With Emacs 23, you could specify special behavior only via
`special-display-frame-alist' and the special case entries of
`special-display-buffer-names' and `special-display-regexps' in some
very restricted manner - use the same window, a window on the same
frame, or a new frame with some predefined properties.

martin