From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11939: 24.1; `save-buffers-kill-emacs' losesminibufferfocuswhenitcalls`list-processes' Date: Mon, 13 Aug 2012 06:51:49 -0700 Message-ID: References: <50156DFE.6090807@gmx.at><50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at> <72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90! 10707@gmx.at> <5026266! 6.2060809@gmx.at> <502! 785DF.1040200@gmx.at> <5028A8FD.60705@gmx .at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1344866045 26992 80.91.229.3 (13 Aug 2012 13:54:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2012 13:54:05 +0000 (UTC) Cc: 11939@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 13 15:54:02 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T0v4Q-0002JT-F8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Aug 2012 15:52:38 +0200 Original-Received: from localhost ([::1]:42235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0v4P-0001SA-Hh for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Aug 2012 09:52:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0v4K-0001Rs-Ag for bug-gnu-emacs@gnu.org; Mon, 13 Aug 2012 09:52:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0v4I-0006FE-25 for bug-gnu-emacs@gnu.org; Mon, 13 Aug 2012 09:52:32 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0v4H-0006FA-Uw for bug-gnu-emacs@gnu.org; Mon, 13 Aug 2012 09:52:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T0vCX-0005h3-Ok for bug-gnu-emacs@gnu.org; Mon, 13 Aug 2012 10:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Aug 2012 14:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11939 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11939-submit@debbugs.gnu.org id=B11939.134486644221861 (code B ref 11939); Mon, 13 Aug 2012 14:01:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 13 Aug 2012 14:00:42 +0000 Original-Received: from localhost ([127.0.0.1]:53501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0vCD-0005gW-TW for submit@debbugs.gnu.org; Mon, 13 Aug 2012 10:00:42 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:32746) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0vCA-0005gO-Nm for 11939@debbugs.gnu.org; Mon, 13 Aug 2012 10:00:40 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7DDq47S031473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Aug 2012 13:52:05 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7DDq3OD006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 13:52:04 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7DDq3XL006199; Mon, 13 Aug 2012 08:52:03 -0500 Original-Received: from dradamslap1 (/10.159.171.13) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Aug 2012 06:52:03 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5028A8FD.60705@gmx.at> Thread-Index: Ac15IxZik1v5ur83S6KlJS2YrcJW1AAL/lSQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63096 Archived-At: > 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.