From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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 12:42:03 +0200 Message-ID: <5007E47B.3050907@gmx.at> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1342694525 16960 80.91.229.3 (19 Jul 2012 10:42:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 Jul 2012 10:42:05 +0000 (UTC) Cc: 11939@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 19 12:42:04 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 1SroBI-0003E8-Hn for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 12:42:04 +0200 Original-Received: from localhost ([::1]:42185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SroBH-0000ct-SP for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 06:42:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SroB7-0000SB-Dl for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:41:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SroB6-0005Iz-1n for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:41:53 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SroB5-0005Iv-UJ for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:41:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SroH4-0007Qg-7J for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Jul 2012 10:48: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.134269484028475 (code B ref 11939); Thu, 19 Jul 2012 10:48:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 10:47:20 +0000 Original-Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SroGN-0007PD-M5 for submit@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:20 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:47390) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SroGL-0007P5-VR for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:19 -0400 Original-Received: (qmail invoked by alias); 19 Jul 2012 10:41:06 -0000 Original-Received: from 62-47-39-3.adsl.highway.telekom.at (EHLO [62.47.39.3]) [62.47.39.3] by mail.gmx.net (mp040) with SMTP; 19 Jul 2012 12:41:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19zsEB/iQJzfKo0BDtn4FbXTOS5fVP8zXpUmxyucW JHlQh3Ea+Dmb/t In-Reply-To: <47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com> X-Y-GMX-Trusted: 0 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:62154 Archived-At: > #1 >> (progn >> (load "~/with-temp-buffer-window.el") >> (shell) >> (setq minibuffer-auto-raise t) ; Optional >> (setq pop-up-frame-function >> (lambda () (make-frame '((minibuffer . nil))))) >> (setq pop-up-frames t)) > > #2 >> (progn >> (setq pop-up-frames t) >> (load "~/with-temp-buffer-window.el") >> (shell)) >> >> and with your usual settings and tell me what you see. Also test it >> with `minibuffer-auto-raise' either nil or t. >> >> If the above work, test also the delete files in dired scenario. The >> first dialogue will probably fail in the usual way, then you have to >> load `with-temp-buffer-window.el' once more and try another time. > > I used my normal setup. I tried #1. No problem. I started again and tried #1 > with nil `minibuffer-auto-raise'. Still no problem. I tried #2. Still no > problem. You should have tried #1 and #2 with emacs -Q. Otherwise, your private settings will shadow #1 and #2 (I tested #1 and #2 here but would like a confirmation). > My setup already has non-nil pop-up-frames, so apparently all that is needed is > your file. If I comment out the load of your file and try #2 then the bugged > behavior reappears. > > So it seems that you have found a solution. Since you do set `pop-up-frames' to non-nil you have inirectly confirmed that it works for your setup. You did not report whether it works for `minibuffer-auto-raise' nil. Can you look into that? >> Finally, try to exit it in various ways, for example by >> deleting some frame during the dialogue. >> I found a not yet 100% reproducible way to crash Emacs doing that. > > I could not reproduce that problem. I was able, after hitting C-x C-c, to click > the corner "X" and thus delete each of the frames. When I did that on the last > frame (the minibuffer frame), an Emacs popup window gave me the question about > killing active processes (instead of the question appearing in the minibuffer). > I clicked the Yes button. Emacs exited normally. > > 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. > But I'm sorry to say that I am totally confused now - not by these recent tests > you've had me do with your code, but by the code fix that I reported for my own > code (on 7/16), where I spoke of 3 fixes, each of which worked. > > Now, none of them work. I am certain that before, when I reported them, that > each of the 3 fixes worked. (And the same is and was true for all Emacs > versions - all worked and now none work.) I do not understand at all. 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? > It is true that if I do not add that test of (eq last-event-frame (window-frame > (minibuffer-window))), which is fix one I chose, then the *Process List* frame > and buffer are current/selected. But that test does _not_ solve the focus > problem. I still cannot type "yes" into the minibuffer frame. 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. > 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'. > So I am totally confused. I am glad at least that you seem to have found a > solution, with your code, for the Emacs 24 case. I'm disappointed and > incredulous, however, about my own "fix" that does not work, especially because > it worked (on 7/16) in all Emacs versions. I have no idea what is going on. Une solution peut en cacher une autre. martin