GNU bug report logs - #11939
24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

Previous Next

Full log

Message #404 received at 11939 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 11939 <at> debbugs.gnu.org
Subject: RE: bug#11939: 24.1; `save-buffers-kill-emacs'
	losesminibufferfocuswhenitcalls`list-processes'
Date: Mon, 13 Aug 2012 06:51:49 -0700

> 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, I suspect, is a fundamental misunderstanding behind this change (and some
other changes in Emacs over the last few years).  Let me politely suggest that
such changes are misguided if the designers think that this is always the way to
go and the answer to everything.

In particular, wanting to deprecate and replace, rather than supplement,
previous constructs, is a mistake, IMHO.  Farther down the road I might see the
light and change my mind, but that is my honest point of view at present.

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'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).

What you've provided is fine for specific places where `display-buffer' is
called and you 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'.

That is what the various "old" user options provide: easy to turn on/off classes
of behavior that affect all `display-buffer' calls.  As opposed to "customizing"
individual `display-buffer' calls (which requires access to modify those calls).
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.
 
> 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.

"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.

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.

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.

> 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.

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.

I am not arguing against the new.  Not at all.

Wanting to jump on board the new, I'm still waiting to see how best to get the
same effects as the "old" using the new.  I'm sure I will get there eventually.
And I'm guessing that there might be some additional unforeseen hiccups for
Emacs Dev that will require still more changes to the new to simulate some
aspects of the "old".  That's OK, and to be expected.

I will say that I am very grateful for your interest and efforts in _getting
this right_.  It would have been all too easy for someone enthused about his new
approach to just throw up his hands and say: it solves all the problems; you are
on your own to figure out how.  Instead, you have spent time trying to
understand and solve the problems raised.  Bravo, and thank you, for that.

Please understand that I am not opposed to the work you have done in making
`display-buffer' (and windows etc.) more coherent, logical, and controllable.
Quite the contrary.  I defended your work when some wanted to simplify parts and
throw some of it overboard.  It seemed to me that you were approaching things
carefully and with an open mind.  You were listening to problems raised and took
them seriously.

IMHO, it is not appropriate now to deprecate the "old", and it might never be.
If the "old" is now no more than a shorthand for a subset of what the new
provides, it can usefully be kept as just such: a shorthand, easy way to get
that subset.

If it turns out - based on _lots_ of user experience and some time - that the
"old" is not so convenient as the new, then the new will replace it organically,
naturally.  Then, and only then, should we deprecate the old: when it truly is
no longer serving any purpose, when it truly has become old.

Thank you for the new, and please do not be in any hurry to force it on users as
a replacement for the "old".  If it is better, sufficient, and easier to use,
users will naturally adopt it with enthusiasm.  Users are not stupid, even if
they are more ignorant than the designers wrt the new, esp. when it is first
made available.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.