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: Sat, 21 Jul 2012 11:13:10 -0700 Message-ID: <96A974694CF64567A3EAB85185AB3A5C@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> <446B437450EC47968D15C20D7142296B@us.oracle.com> <500A8C0E.4040006@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 1342894426 23765 80.91.229.3 (21 Jul 2012 18:13:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Jul 2012 18:13:46 +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 Jul 21 20:13:45 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 1SseBV-0004D0-90 for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jul 2012 20:13:45 +0200 Original-Received: from localhost ([::1]:52225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SseBU-00026N-6N for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jul 2012 14:13:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36234) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SseBQ-00025u-Of for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 14:13:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SseBP-0000VK-1q for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 14:13:40 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SseBO-0000VE-UE for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 14:13:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SseHa-0005VB-Hk for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 14:20: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, 21 Jul 2012 18:20: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.134289479221129 (code B ref 11939); Sat, 21 Jul 2012 18:20:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 18:19:52 +0000 Original-Received: from localhost ([127.0.0.1]:55859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseHO-0005Uj-Rj for submit@debbugs.gnu.org; Sat, 21 Jul 2012 14:19:51 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:44505) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SseHL-0005Ua-Jw for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 14:19:48 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6LIDL0l009890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2012 18:13:21 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6LIDJE0005313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jul 2012 18:13:20 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6LIDJIQ029005; Sat, 21 Jul 2012 13:13:19 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jul 2012 11:13:19 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <500A8C0E.4040006@gmx.at> Thread-Index: Ac1nMCWREn6FNGxRSSKBDn+crtxr9AAGWyzA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:62248 Archived-At: > Are you sure you started Emacs again before you went through > (progn > (setq pop-up-frames t) > (load "~/with-temp-buffer-window.el") > (shell)) > > Here I get a new frame in the foreground, focussed, with the process > list in its root window and the `yes-or-no-p' prompt in its minibuffer > window. Please try once more. If this does not work on your > system, we might have a smoking gun. My bad, I think. I think what I did was forget to load your code (!). I tried again, using emacs -Q with the following, and it did what you say (i.e., no problem): (progn (load-file "~/drews-lisp-20/contrib/cygwin-mount.el") (load-file "~/drews-lisp-20/setup-cygwin.el") (setq pop-up-frames t) (load "~/with-temp-buffer-window.el") (shell)) > >> 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. > > It's a NOOP for #2. I tried also with the above code, inserting (setq minibuffer-auto-raise nil) after (shell). No problem, and no difference from not having that code. > > 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). > > That's what happens here in scenario #2. Same here. > > Got it. I don't get a crash (on MS Windows). Are you > > seeing the crash on MS Windows also? > > On Windows. Hm. > > 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. > > Yes. But maybe you could adapt your buffer display function > accordingly. What do you mean? > > What about other Emacs releases - are relevant at > > all in this context? > > Should we expect that your code can help them also? > > If you have an appropriate hook. Meaning? Is this something I can do (how)? > >> 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'? > > I think so. > > > 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. > > If your `1on1-fit-minibuffer-frame' can hook in after the new > frame pops up, it might be worth a try. With > `temp-output-buffer-show' the only suitable hook at your > disposition is `temp-buffer-show-hook' where selecting another > window won't work because the hook's call is wrapped in > `with-selected-window'. But you can remember the new > frame's window and select it later, for example, in > `post-command-hook'. I don't understand everything you said, but that's OK - I can refer back to it later if I need to try to understand more. I tried adding this at the end of `1on1-fit-minibuffer-frame', instead of guarding the function with the test (eq last-event-frame (window-frame (minibuffer-window))): (redirect-frame-focus last-event-frame (window-frame (minibuffer-window))) Is that what you meant? That works, in all Emacs versions, even without your code! And so does using this in its place: (select-frame-set-input-focus (window-frame (minibuffer-window))) (Is there a difference? What is the advantage of either?) But there is a problem, for Emacs 23+. It happens in my setup, with the call to `redirect-frame-focus' added at the end of `1on1-fit-minibuffer-frame'. I can also repro it with a reduced version of my setup - essentially loading oneonone.el and fit-frame.el and doing (add-hook 'post-command-hook '1on1-fit-minibuffer-frame) so that I pick up the redirection that is needed. [BTW, for oneonone.el users who do not use fit-frame.el I suppose I will put the redirection directly on `post-command-hook', instead of putting it at the end of `1on1-fit-minibuffer-frame'. I will no doubt have to use a similar guard: do nothing unless (a) the minibuffer window is active, (b) the minibuffer frame is `last-event-frame', and (c) the minibuffer window is alone in its frame.] Anyway, this the problem: 1. When I do C-x C-c, and respond to the yes/no question, it seems I must wait a tiny bit before typing yes/no. Otherwise, the first char (e.g. `y') is lost, so I end up with just `es' (I see the `y' nowhere). Not a big deal; just FYI. 2. If I type "no," and then I do `C-x k', then even though *Process List* has its frame border highlighted as if it is selected, the buffer proposed for deletion is *shell*. OK, so I kill *shell*, and confirm ("yes') to kill its processes also. (BTW, `C-x k' in my setup also deletes the window/frame.) So far, so good. But if I try to use `C-x k' again to kill *Process List*, then, as soon as I hit the `k': a. The default buffer to kill is proposed as some other buffer, not *Process List* (in my setup the default value is automatically inserted in the minibuffer, so I can see it without doing M-n). b. Emacs crashes, but gives no "fatal error" dialog box - hence no way to access gdb. It just directly shows the MS Windows dialog box for sending an error report to MS. When I click yes/no in that dialog box Emacs exits (disappears). I can repro this systematically, but there seems to be no way to use gdb. If I do something else instead of `C-x k' - e.g. `C-x o', then there is no problem. I can, for instance, use `C-x o' to move among frames (`C-x o' moves to the other frame in my setup, if there is no other window on the same frame), coming eventually to *Process List*, and then use `C-x k' to kill *Process List*. This crash is reproducible also with Emacs 23.3, not just with the latest Emacs 24 build. It does not happen with Emacs 22.3, however. Dunno whether this crash is related to the crashes you are seeing. Anyway, it seems we are very close, for my needs. I suppose I can put that redirection on `post-command-hook' (instead of in `1on1-fit-minibuffer-frame', which some oneonone.el users will not use), and things should generally work. I will try that next. Another problem I saw, when I used only a reduced version of my setup, was that (presumably because of the redirection?) `query-replace' no longer worked: When I hit `y' or `.' to replace, no replacement occurred. I will try later to repro this etc. I want to get this info off to you now so you can digest it. Thx - Drew