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: Sat, 11 Aug 2012 09:58:28 -0700 Message-ID: References: <5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><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> 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 1344704399 26389 80.91.229.3 (11 Aug 2012 16:59:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 11 Aug 2012 16:59:59 +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 Sat Aug 11 18:59:58 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 1T0F2S-00021w-AT for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Aug 2012 18:59:48 +0200 Original-Received: from localhost ([::1]:53892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0F2R-00063D-JY for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Aug 2012 12:59:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0F2N-000633-DZ for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 12:59:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0F2L-0000p3-0r for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 12:59:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0F2K-0000oz-TO for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 12:59:40 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T0FAQ-0004Kv-5s for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 13:08:02 -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: Sat, 11 Aug 2012 17:08:02 +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.134470482316601 (code B ref 11939); Sat, 11 Aug 2012 17:08:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 11 Aug 2012 17:07:03 +0000 Original-Received: from localhost ([127.0.0.1]:49733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0F9S-0004Jg-P4 for submit@debbugs.gnu.org; Sat, 11 Aug 2012 13:07:03 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:34998) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0F9Q-0004JH-IJ for 11939@debbugs.gnu.org; Sat, 11 Aug 2012 13:07:01 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7BGwapk025775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 16:58:37 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7BGwagF023484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 16:58:36 GMT Original-Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7BGwaGY008096; Sat, 11 Aug 2012 11:58:36 -0500 Original-Received: from dradamslap1 (/10.159.168.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Aug 2012 09:58:36 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50262666.2060809@gmx.at> Thread-Index: Ac13pAqcRKOqp2MTQ5eCMZz5OP56nwAK/fQw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:63051 Archived-At: > > Should it not _always_ be the case that > > `special-display-popup-frame' pops up the buffer in a frame, > > i.e., ensures that its display is clearly visible? > > Its doc-string says... Yes, I know what the doc string says. I raised a question about the design: the desired behavior. The doc string would then follow from whatever was decided about the behavior. > I suppose FUNCTION should be held responsible for raising the frame if > needed. That's just the question I raised - should it? That is the current design (hence the doc string). But is it the best approach? Dunno. In that case, `s-d-p-f' gets completely replaced and adds nothing to the party. It does not necessarily pop up a frame showing the buffer. The FUNCTION passed as (car ARGS) is presumed to "do the work". But "the work" has no meaning, not even a suggested meaning - FUNCTION might well not raise the frame or even display the buffer. That's OK (it's one approach). But is it reasonable to suppose that there are many (any?) use cases where you would not want the frame raised? To be clear: I do not have a problem with the current approach (and I've now changed my version, likewise, to not raise (or fit) the frame in that case). But if we keep that design then it might be clearer to state what "the work" is generally expected to be, i.e., that it typically means displaying the buffer and raising its frame. E.g.: If ARGS is a list whose car is a symbol then use (car ARGS) as a function to do the work: display the buffer and raise its frame. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pass it BUFFER as first argument, and (cdr ARGS) as the rest of the arguments. (See also bug #8853 wrt the last phrase - this regression is still not fixed.) > I don't understand why you insist on using, advising, or redefining > `special-display-popup-frame'. Customizing > `display-buffer-base-action' should be all you want. What part of must-work-with-releases-other-than-just-24 did you not get? You add a new knob, such as `display-buffer-base-action', and you think that that takes care of everything. Maybe it does for Emacs 24, but the knob does not even exist prior to 24. You are concerned only with the latest Emacs release. I, like many (most?) users, am not. > BTW: With with-temp-buffer-window.el it's possible to customize > `temp-buffer-resize-frames' and automatically resize temporary frames. OK, good to know. My need is not just for temporary frames (whatever that term might mean), and it is generally not only for Emacs 24+. But that is definitely good to know.