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: Tue, 17 Jul 2012 11:50:16 +0200 Message-ID: <50053558.4040808@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> 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 1342518858 24136 80.91.229.3 (17 Jul 2012 09:54:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 17 Jul 2012 09:54:18 +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 Tue Jul 17 11:54:18 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 1Sr4Tx-00085G-TM for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Jul 2012 11:54:18 +0200 Original-Received: from localhost ([::1]:34735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr4Tx-0001Bp-3g for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Jul 2012 05:54:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr4Tr-0001BV-Ly for bug-gnu-emacs@gnu.org; Tue, 17 Jul 2012 05:54:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sr4Tk-0001Xf-N4 for bug-gnu-emacs@gnu.org; Tue, 17 Jul 2012 05:54:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sr4Tk-0001Xa-JX for bug-gnu-emacs@gnu.org; Tue, 17 Jul 2012 05:54:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sr4ZX-0000a0-JM for bug-gnu-emacs@gnu.org; Tue, 17 Jul 2012 06:00:03 -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: Tue, 17 Jul 2012 10:00:03 +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.13425192022211 (code B ref 11939); Tue, 17 Jul 2012 10:00:03 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 17 Jul 2012 10:00:02 +0000 Original-Received: from localhost ([127.0.0.1]:45341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sr4ZV-0000ZA-45 for submit@debbugs.gnu.org; Tue, 17 Jul 2012 06:00:02 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:33937) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sr4ZS-0000Z3-T1 for 11939@debbugs.gnu.org; Tue, 17 Jul 2012 06:00:00 -0400 Original-Received: (qmail invoked by alias); 17 Jul 2012 09:49:19 -0000 Original-Received: from 62-47-34-58.adsl.highway.telekom.at (EHLO [62.47.34.58]) [62.47.34.58] by mail.gmx.net (mp030) with SMTP; 17 Jul 2012 11:49:19 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/YRR5WynrYfTXBKD2rVZxRBrkCZVQlZVVpDHNQs7 RDjJu2ma1+L5YG 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:62037 Archived-At: > In my code I put command `1on1-fit-minibuffer-frame' on `post-command-hook'. > That function fits the standalone minibuffer frame to its "buffer contents" > (taking Icomplete overlays into account etc.). > > The function assumes that it is called from the minibuffer, i.e., that the > selected frame is the standalone frame. Which it is... Why does that function _assume_ that? It should check it. > But something apparently changed the focus in this case - I'm guessing, as I > said before, that it was the popping up of the new frame. And some second > command is involved at that point - apparently `handle-switch-frame'. So `1on1-fit-minibuffer-frame' assumes that the selected frame is the standalone minibuffer frame and that that frame has focus. Why don't you verify all that in the function's body? > So because of `post-command-hook', `1on1-fit-minibuffer-frame' got called a > second time, and this time with the previously selected frame being selected > (i.e., the frame that was selected prior to entering the minibuffer). The > minibuffer was still active, ... you mean `active-minibuffer-window' returned the window of the minibuffer-only frame ... > but the selected frame was another one (e.g. > *Process List*). > > I came up with three alternative fixes that work - I chose the second one: > > 1. The first fix is to call `select-frame-set-input-focus' at the end of > `1on1-fit-minibuffer-frame'. > > I can tell by debugging using `message' that the frame switch happens outside > `1on1-fit-minibuffer-frame': the selected frame is the minibuffer frame the > first time `1on1-fit-minibuffer-frame' is called, right up till the end. But it > is another frame the next time `1on1-fit-minibuffer-frame' is called, which > appears to be immediately afterward. > > So why does this fix work? Dunno. Even though without adding the call to > `select-frame-set-input-focus' the frame is correct when the first call to > `1on1-fit-minibuffer-frame' ends, if I do not add that call then it is incorrect > for the second `1on1-fit-minibuffer-frame' call. Well that's understandable > from a `switch-frame' event. > > But what's not clear to me is why calling `select-frame-set-input-focus' at the > end of the first call to `1on1-fit-minibuffer-frame' fixes things. As I said, > the frame switch seems to happen between the two calls, yet selecting the > minibuffer frame before the end of the first call solves the problem. Maybe > this has something to do with the redisplay code? No idea. You have two calls from `post-command-hook': The first seems due to `save-buffers-kill-emacs' preliminary terminating with a `yes-or-no-p' question which does not affect frame or focus. The second should come from `handle-switch-frame' as a consequence of emacs being called back by the window manager. IIUC `handle-switch-frame' calls do_switch_frame with TRACK equal 0, so focus is not affected by `handle-switch-frame'. But focus has been redirected to the new frame by the window manager and emacs should probably adapt to that situation because that is the frame that gets the keystrokes. Now if whatever you want to do after `handle-switch-frame' has terminated happens in the new frame, there's no problem. We have a problem if we want to make things happen in another frame and for that purpose we have to redirect focus to that other frame. That's what you apparently do via the `select-frame-set-input-focus' call at the end of the first `post-command-hook' execution since `handle-switch-frame' won't change focus afterwards. Looks like a very fragile hack. > 2. The second fix is to have `1on1-fit-minibuffer-frame' do nothing unless: > > (eq last-event-frame > (save-selected-window > (select-window (minibuffer-window)) (selected-frame))) Is that (eq last-event-frame (window-frame (minibuffer-window)))? This means that you don't do anything in this case so apparently some side-effect gets suppressed. Which side-effect? > 3. The third fix is to have `1on1-fit-minibuffer-frame' do nothing unless: > `this-command' is not eq to `handle-switch-frame. Same as before. What is the side-effect of `1on1-fit-minibuffer-frame'? > In sum, this is my guess: The creation of the new frame provoked a > `switch-frame' event, which, because of `post-command-hook' caused > `1on1-fit-minibuffer-frame' to be called a second time, this time with the new > frame selected because the last command was `handle-frame-switch'. I think you should make sure two things: (1) `1on1-fit-minibuffer-frame' should do something iff the frame in question is a minibuffer frame. (2) `1on1-fit-minibuffer-frame' should avoid having any side-effects wrt window selection or focus unless you explictly want that. martin