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: Thu, 19 Jul 2012 12:42:10 +0200 Message-ID: <5007E482.3030401@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> 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 1342694531 17053 80.91.229.3 (19 Jul 2012 10:42:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 Jul 2012 10:42:11 +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:11 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 1SroBL-0003H1-EP for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 12:42:07 +0200 Original-Received: from localhost ([::1]:42352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SroBK-0000iI-Pg for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 06:42:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SroBD-0000Sc-Fi for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:42:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SroB6-0005JH-MF for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:41:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SroB6-0005JD-J4 for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 06:41:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SroH4-0007Qr-Ut 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.134269484828505 (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:28 +0000 Original-Received: from localhost ([127.0.0.1]:49607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SroGW-0007Ph-17 for submit@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:28 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:58054) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SroGS-0007PS-Cj for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 06:47:25 -0400 Original-Received: (qmail invoked by alias); 19 Jul 2012 10:41:12 -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 (mp020) with SMTP; 19 Jul 2012 12:41:12 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19l868px25lf1++GgYh+PtM216hjT2LMhvh3pTzsg 93nHt98+vZ83qB In-Reply-To: <1888F8FFBF624D39920F56673A91C4B6@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:62156 Archived-At: >> Can a minibuffer-less frame get the focus? > > In what scenario? I don't know what you are asking. > > Of course a minibuffer-less frame can get the focus either programmatically (a > function executing in the minibuffer can select another frame) or through user > interaction (the user can click another frame, etc.). Here and everywhere else I meant focus redirection for interaction with the minibuffer. Obviously `redirect-frame-focus' can redirect focus to a minibuffer-less frame. 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 (); and read_minibuf calls choose_minibuf_frame, so if a new frame doesn't have a valid minibuffer window, emacs should abort. 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. >> >> 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? >> > >> > See above - you already asked that. It _is_ the >> > minibuffer frame for the call that I expected. I did not >> > expect the second call provoked by the frame switch >> > command (via post-command-hook), with the wrong frame focused. >> >> Can you check somehow that the minibuffer-less frame is focussed? > > Again, I don't know what you mean, or how to do that. Probably by checking whether the focus of the minibuffer-less frame A is redirected to the minibuffer-equipped frame B. >> > No, I meant only that the minibuffer was still active: >> > accepting typed input. >> >> When? > > Let's not get confused with the language here. I was not talking about the > minibuffer _frame_ accepting input, i.e., having the focus. That is of course > the problem. > > I was talking only about the minibuffer still being active (not exited) But what does that mean in practice? Apart from looping. > and > `read-from-minibuffer' still expecting input. Obviously so. > It is still my guess that the focus _was_ directed to the minibuffer for/by > `read-from-minibuffer', but that thereafter the new frame was popped up and the > window mgr gave it the focus (i.e., took focus away from the minibuffer frame). From the window manager's POV the minibuffer-less frame does have focus. The emacs redirection mechanism works on top of that. > No, I do not have any proof of that, but that's my conceptual model so far. > > But you understand this stuff at a better, lower level than I: you understand it > at the level of windows etc. I understand next to nothing about WM windows. > It is no doubt correct to speak of the minibuffer > window and not (as I did, waving my hands) of the "minibuffer" expecting input. It makes a difference if you have a minibuffer-less frame that has no minibuffer window it can direct input to. martin