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

[martin rudalics]

> As you know, I am no expert on this stuff - I barely understand the new
> approach, certainly so wrt details.  I have some experience with parts of the
> "old" approach, and I've seen some of the pain you've gone through to try to
> enable the new to handle some of the straightforward cases of the old.  It has
> not always been so simple, has it?

You are mistaken here.  The "new" approach was _entirely_ coded by Chong
based on ideas by Stefan.

> You've succeeded, AFAICT, but it has not been obvious.  Granted, part of the
> difficulty is that you were not familiar with some of the "old" (use cases, 
for
> example).  Still, it is not clear to me that the new is a reasonable,
> straightforward replacement for the "old".
>
> Here's the misunderstanding, as I see it:
>
> "You can call `display-buffer' with some special-purpose alist elements..."
> misses the point.  It is not just that "you can" but that "you MUST" (if you
> intend this as a replacement rather than an addition).

As you know very well the old approach is still supported.  And I intend
"this" as an enhancement rather than a replacement or an addition.

> What you've provided is fine for specific places where `display-buffer' is
> called and you

Who's "you" here?

> want to give those calls a particular behavior.  It is not ideal
> AFAICT for a package/user that wants to provide/obtain a particular class of
> behavior across all calls of `display-buffer'.

The new approach is superior because it allows packages to specify the
behavior they consider most suited and it allows the user to override
that.  This distinction was not clear in the old approach where a user's
customizations could be deliberately turned off by packages that
temporarily bound these options to nil.

> That is what the various "old" user options provide: easy to turn on/off 
classes
> of behavior that affect all `display-buffer' calls.

These confer to `display-buffer-base-action' in the new approach.  A
package binding this variable is a package I would remove immediately.

> As opposed to "customizing"
> individual `display-buffer' calls (which requires access to modify those 
calls).

I miss you here.

> That is the power (as well as the limitation) of dynamically scoped global
> variables: they can affect behavior deep down, with just a flip of the switch.

`display-buffer-base-action' provides that switch.

> "You can get" -> "You MUST define".  You must have available the "when and
> where" times and locations, and you must control/customize them.  You cannot 
so
> simply/easily get a special behavior across all such "when and where" at once.

In which regard does what you write here differ from earlier versions of
Emacs?

> To be clear, I do not say that one _cannot_ do with the new what one can do 
with
> the "old".  But it does not seem so easy to do - so far.  We cannot even seem 
to
> get a straightforward "migration table" added to the doc, that clearly tells 
you
> how to move from "old" to new.

This is partially true.  For example, I'd never explain how a package
can override a user's customizations.

> It is not really up to me to prove that the new cannot (or cannot easily) do 
the
> job, even if I believed that.  It is up to those providing the new to show 
that
> it can - IF they intend to deprecate & replace the "old".  Hand waving and
> repeating that "you can" do anything you like with the new is not very
> persuasive.  Yes, this is Lisp: you can do nearly anything.  But that is not
> much help, I'm afraid.  It just doesn't cut the mustard.
>
> Consider that we users are not so bright, and we need someone to show us the 
way
> step by step.  IOW, apply the same logic that we ask of users reporting bugs:
> think of the reader as a six-year old who asks for a bit of hand-holding.
> Believe me, that will not hurt, and even the explainer can end up learning
> something now and then from the teaching.

Users who ask will get the appropriate answer.  Unfortunately,
deprecating options seems the only way to get them do that.  And in this
regard, I consider myself a user just like you.

> Fair enough.  The new is more fine-grained and apparently more general.  I can
> see and appreciate that.  But those particular "very restricted" special cases
> are important use cases - at least for me.  For me, the "old" does the job 
quite
> well - the "very restricted" job it was intended to do.

For some users it was bad karma that applications were allowed to
overrule them in these important use cases.

martin