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 itcalls `list-processes' Date: Sat, 21 Jul 2012 13:02:05 +0200 Message-ID: <500A8C2D.8040005@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> <50053558.4040808@gmx.at> <28CDFF761F104E109F9F24CD9BEBD8DD@us.oracle.com> <5006E151.5080301@gmx.at> <1888F8FFBF624D39920F56673A91C4B6@us.oracle.com> <5007E482.3030401@gmx.at> 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 1342868572 14755 80.91.229.3 (21 Jul 2012 11:02:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Jul 2012 11:02:52 +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 Sat Jul 21 13:02:51 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 1SsXSS-0004GV-Eo for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jul 2012 13:02:48 +0200 Original-Received: from localhost ([::1]:43976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXSR-0005l3-Mi for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jul 2012 07:02:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXSL-0005ju-Nu for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 07:02:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SsXSK-00085i-9b for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 07:02:41 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXSK-00085J-5g for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 07:02:40 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SsXYT-0002O6-RU for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 07:09: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: Sat, 21 Jul 2012 11:09: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.13428688879091 (code B ref 11939); Sat, 21 Jul 2012 11:09:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 11:08:07 +0000 Original-Received: from localhost ([127.0.0.1]:54085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsXXa-0002MZ-Qf for submit@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:07 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:55197) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SsXXW-0002M0-1C for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:03 -0400 Original-Received: (qmail invoked by alias); 21 Jul 2012 11:01:39 -0000 Original-Received: from 62-47-44-153.adsl.highway.telekom.at (EHLO [62.47.44.153]) [62.47.44.153] by mail.gmx.net (mp038) with SMTP; 21 Jul 2012 13:01:39 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+e4tlNTiWe4vxJaltcx2guE5SuF5voFYX/Xjrmwq yqV0zRSIWn6sB7 In-Reply-To: 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:62229 Archived-At: >> But choose_minibuf_frame has this >> >> /* I don't think that any frames may validly have a >> null minibuffer window anymore. */ >> if (NILP (sf->minibuffer_window)) >> abort (); > > Wow, that comment seems weird. Unless a frame that has nil as the value of its > `minibuffer' frame parameter is still expected to have a minibuffer _window_. > That's a distinction that is beyond me. I do not claim to understand things at > the Emacs window level. Usually, each frame must have a minibuffer window. How else should `read-minibuffer' work? But within the C routines this invariant seems too strong. > But certainly there can be frames that have no minibuffer - their `minibuffer' > frame parameter value is nil. That's a different story. IIUC only the selected frame must have the minibuffer_window slot always set. >> and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't >> have a valid minibuffer window, emacs should abort. > > What does abort mean here - does it mean that Emacs exits? Ungracefully, yes. >> If it does, the latter >> if (!EQ (mini_frame, selected_frame)) >> Fredirect_frame_focus (selected_frame, mini_frame); >> >> in read_minibuf should redirect focus but apparently it doesn't. > > Again, are you sure it does not? I've been (stubbornly) guessing that it always > does, but then, in the problematic case we've been looking at, the focus is > grabbed away and given to the new frame that is popped up. > > I understand that you don't see it that way, that you instead guess that in this > problematic case there is never any redirection of focus to the minibuffer > frame. But I haven't yet understood why you think that. (I do not say you are > wrong.) As explained many times before I'm just speculating. Note, however, that the redirection in the code above works only for the selected frame. That's why I ask the `yes-or-no-p' questions with the new frame selected. >> Probably by checking whether the focus of the minibuffer-less >> frame A is redirected to the minibuffer-equipped frame B. > > I don't know how to do that. > > And in `1on1-fit-minibuffer-frame' I do not know how to find out what the > minibuffer-less frame is. That function is just invoked by `post-command-hook'. > > It seems that in the problematic case it is command `handle-switch-frame' that > is the command current when `post-command-hook' does its thing here. But I > don't know how to determine what frame was switched to. I can check > `selected-frame', which is what I do, but I'm not sure what you are suggesting I > do. Why don't you try what I suggested earlier: Put something on `mouse-leave-buffer-hook' and in a `pre-' or `post-command-hook' check whether that something got executed. Then you can be sure that somewhere in between a `handle-switch-frame' interfered. > OK, but did the minibuffer frame ever receive the focus, after > `read-from-minibuffer' was invoked? That's the question that I think we are > assuming different answers to. I'm guessing yes, and I think you are saying no. > I'm guessing yes, but then the window mgr gave the focus instead to the new > frame it created. So you mean the following happens: (1) Emacs ask a `yes-or-no-p' with input focus directed to frame A. (2) The window manager redirects focus to the new frame B and the `handle-switch-frame' which should redirect focus from B to A gets delayed as long as Emacs waits for minibuffer input. > OK. What's needed I guess is to make sure somehow that every frame redirects > input to the minibuffer frame when the minibuffer becomes active. Which won't help in (2) above. > Perhaps it would help to imagine the new frame scenario a bit like the > switch-to-*Completions*-frame scenario (dunno). > > As I mentioned in my other reply today, you can, when the minibuffer is active, > explicitly switch the focus to the *Completions* frame, to do something there > (e.g. move to some completion candidate). Which function precisely does that? > So a possible (hack) solution, if we could detect that unprogrammed (in Emacs) > focus switch, might be to automatically switch focus back to the minibuffer > frame (IF the minibuffer is active). Or assume that the focus switch happened and react accordingly. martin