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: Sat, 21 Jul 2012 13:01:54 +0200 Message-ID: <500A8C22.7000706@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> <5007E46C.7030206@gmx.at> <55F70CDDACA84503826C907CDE8CE684@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 1342868572 14760 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:52 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-0004GU-3s for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jul 2012 13:02:48 +0200 Original-Received: from localhost ([::1]:43968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXSR-0005ki-E7 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]:38127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXSN-0005jx-91 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 1SsXSL-00089X-Ek for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 07:02:43 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SsXSL-00088y-AL for bug-gnu-emacs@gnu.org; Sat, 21 Jul 2012 07:02:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SsXYU-0002OB-Eo 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: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.13428689079138 (code B ref 11939); Sat, 21 Jul 2012 11:09:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 21 Jul 2012 11:08:27 +0000 Original-Received: from localhost ([127.0.0.1]:54092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SsXXt-0002NI-98 for submit@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:26 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:56634) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SsXXp-0002N4-IV for 11939@debbugs.gnu.org; Sat, 21 Jul 2012 07:08:23 -0400 Original-Received: (qmail invoked by alias); 21 Jul 2012 11:01:28 -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 (mp019) with SMTP; 21 Jul 2012 13:01:28 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1838YUVhwk3XRy+QkSsGJiHl/HlXVXeprNeWsVl1C /vCNfqBDZBUX7A In-Reply-To: <55F70CDDACA84503826C907CDE8CE684@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:62230 Archived-At: > Now maybe what was really meant is that if X redirects to Y and Y redirects to Z > then X ends up redirecting to Z. That would make sense (and also go without > saying). Dunno. Maybe because it would be too easy to introduce circular redirection this way. >> Now suppose a minibuffer-only frame is selected and had focus directed to >> itself. If now a minibuffer-less frame gets selected, focus will be >> directed to that frame which hardly makes sense to me. > > I agree. But why would someone redirect the minibuffer frame's focus to itself? Indeed, that would not be reasonable. > What are you envisioning? I was only speculating. >> Someone (maybe Jan) once said that it's hard to override any such >> decisions when they are made by the window manager. > > I did not mean override (prevent/nullify). I meant automatically take remedial > action after the window manager's autofocus takes effect. I.e., automatically > move the focus back where it was. I'm not quite sure what "after" means in this context. IIUC Emacs is not informed that the frame has been posted on screen. It will know about it only implicitly when it's passed input directed to that frame. >> IIUC creating a WM window (via CreateWindow) returns a handle to a new >> WM window independently from whether that window already >> appears on the screen and/or obscures other windows. >> >> I don't know whether and how the window manager informs Emacs >> that a window has appeared on the screen. I suppose it doesn't >> and that information is passed to emacs implicitly >> when the user "selects" that window by using the keyboard or >> the mouse. > > How does Emacs determine the selected frame? Doesn't the code of > `selected-frame' help understand this? Emacs selects a new frame. But if it's minibufferless, it doesn't necesarily redirect input to the minibuffer frame. IIUC it does so only when it reads input from that frame. > I did not really mean "redirects the prompt". I was thinking of it moving the > input focus (which would also put the prompt where that focus is, presumably). I suppose we mean the same here. > My guess was/is that it might always move the focus to the minibuffer frame, but > that the focus is then moved away from it to the new frame that is popped up. The window manager moves the focus to the new frame and Emacs selects it. But Emacs apparently does not redirect input focus. > How do you know that that is not what happens? I.e., how do you know that there > are some situations where the focus is *not* (initially) switched to the > minibuffer frame? (I'm not saying you are wrong - just wondering how you know > that.) I have no other explanation. >> From what you said it seems to work as long as no new frames are >> created. When a new frame is created, it may take some time for this >> mechanism to adapt itself to the new configuration. > > Perhaps, but waiting does not help. Perhaps you meant that there is some > timeout and if things are too slow then the focus is automatically moved to the > new frame? My speculation is still the same: The window manager focuses the new frame and Emacs does not redirect input to the minibuffer frame. martin