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' loses minibuffer focus when it calls `list-processes' Date: Thu, 19 Jul 2012 10:43:15 -0700 Message-ID: <446B437450EC47968D15C20D7142296B@us.oracle.com> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@gmx.at> <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> <5003DAF2.2060400@gmx.at> <50043C3D.7090201@gmx.at> <208B7D7BB4BC4339ADCC1166F76C1CD2@us.oracle.com> <500449B7.6070309@gmx.at> <023F63BCBF9442EBAEDCCE9D8A59E5E4@us.oracle.com> <5005354E.6040306@gmx.at> <62CF21F0010048E2BC1391192EB943FF@us.oracle.com> <5006E14B.3000407@gmx.at> <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> <5007E47B.3050907@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 1342719841 12182 80.91.229.3 (19 Jul 2012 17:44:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 Jul 2012 17:44:01 +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 Thu Jul 19 19:43:59 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 1SrulX-0005CY-Qi for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 19:43:56 +0200 Original-Received: from localhost ([::1]:37160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrulX-0001JX-5u for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 13:43:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrulU-0001IM-0x for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:43:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrulS-0002XC-K5 for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:43:51 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrulS-0002X4-G4 for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:43:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SrurS-0003jJ-9b for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:50: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: Thu, 19 Jul 2012 17:50: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.134272017514288 (code B ref 11939); Thu, 19 Jul 2012 17:50:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 17:49:35 +0000 Original-Received: from localhost ([127.0.0.1]:51134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Srur1-0003iP-8H for submit@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:35 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:28908) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sruqy-0003iG-N1 for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:33 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6JHhHcF021514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 17:43:18 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 q6JHhGqo011196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 17:43:17 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6JHhGDM000679; Thu, 19 Jul 2012 12:43:16 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2012 10:43:16 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5007E47B.3050907@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac1lmwHphdxJHQrqTYCJlIvGNpd52QAJJpYg 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:62167 Archived-At: > >> and with your usual settings and tell me what you see. > > You should have tried #1 and #2 with emacs -Q. Sorry, I thought that's what you meant by "with your usual settings". > Otherwise, your private settings will shadow #1 and #2 > (I tested #1 and #2 here but would like a confirmation). #1 (emacs -Q): No problem. #2 (emacs -Q): Does not work. The *Process List* frame is in front, and the question is posed in the minibuffer of the *shell* frame. Typing seems to go nowhere, but when I hit RET after typing I get this error msg: yes-or-no-p: Buffer is read-only: # Interestingly, If I then try C-x C-c from *Messages*, after manually bring that frame to the front, then again *Process List* is moved to the front and the question is posed in the *Messages* frame. I expect that info might help, and perhaps you guessed already that that would happen. > You did not report whether it works for `minibuffer-auto-raise' nil. > Can you look into that? It is nil by default, no? So the tests for #2 test that. But #1 with the value nil works also. The only difference is that with the value nil the *Process List* frame is foremost (in front), and with it t the *shell* frame is in foremost. It's a choice, I guess, whether it is more important to see all of the question (prompt) or to see the *Process List* buffer completely. I'm not sure I have a settled opinion about that. In the case of emacs -Q, where there is no standalone minibuffer frame, I think the best behavior (if possible) would be to have the question appear in the minibuffer of the *Process List* frame (and have that frame be foremost). In the case of a standalone minibuffer frame, the best behavior is probably to always have the minibuffer frame foremost (at least when it asks a question). Typically, a user with a standalone m. frame has it positioned out of the way as much as possible. In my case, for instance, it stretches across the bottom of my screen (and new frames are popped up by the window mgr at or near the top of the screen). > > Perhaps the crash you see is related to bug #11984, which > > I see mentioned in passing? > > No. The crash happens because the following assumption in frame.c > > /* We know that there must be some frame with a minibuffer out > there. If this were not true, all of the frames present > would have to be minibufferless, which implies that at some > point their minibuffer frames must have been deleted, but > that is prohibited at the top; you can't delete surrogate > minibuffer frames. */ > if (NILP (frame_with_minibuf)) > abort (); > > does not always hold during the exit dialogue. And it's bad > because it crashes Emacs when I try to avoid the exit because > of a running subprocess. Got it. I don't get a crash (on MS Windows). Are you seeing the crash on MS Windows also? > Trivial. At the time you wrote the "fixes" you had "fixed" it already > by doing something else. Now you "just" have to find out > what else you did then ;-) Are you sure you ran your changes without > my file loaded? No, I'm not sure. In fact, I thought about that after sending my last mail (I was tired at the time). And looking over the thread I see now that I must have been loading your (earlier) code also. The problem I was looking into at the time was why your code made things work with emacs -Q but not with my setup. The fix to my code no doubt enabled your fix to do its job. But I thought that I had tested with all Emacs versions, and they all worked after my fix. I'll have to revisit this when I get some time. I imagine that your code is applicable only to Emacs 24+ (is that right?), so it could not have helped fix things with my setup for other Emacs versions. > If you use Emacs 24.1 without my changes, then `list-processes' will > pop up a new frame and give it focus. When it now asks the `y-or-n-p' > question you _are_ lost if the new frame does not have a minibuffer and > you can't redirect it to one. Got it. What about other Emacs releases - are relevant at all in this context? Should we expect that your code can help them also? > > All that happens is that `1on1-fit-minibuffer-frame' does > > nothing, and that does not help with the frame focus problem. > > Similarly if I, instead of that test, add the call to > > `select-frame-set-input-focus' at the end of the function - that > > too no longer is a fix. > > Try explicitly redirecting the focus from the new frame to the > minibuffer-only frame via `redirect-frame-focus'. Where? At the end of `1on1-fit-minibuffer-frame', instead of `select-frame-set-input-focus'? And would this be in order to try to make things work even without your code (e.g., for older Emacs versions)? Because if not I do not need to do it, since the code I have now already works well in Emacs 24, when I use your code also. IOW, I'm not clear what you are suggesting, and what problem it might solve. If it is a possible cure for the problem in other Emacs versions, e.g. without your code, then I'll definitely try it. > Une solution peut en cacher une autre. :-D Ca y est.