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: Thu, 19 Jul 2012 10:43:25 -0700 Message-ID: <55F70CDDACA84503826C907CDE8CE684@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> <5007E46C.7030206@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 1342719842 12184 80.91.229.3 (19 Jul 2012 17:44:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 19 Jul 2012 17:44:02 +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 Thu Jul 19 19:43:58 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 1SrulZ-0005Cp-5p for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 19:43:57 +0200 Original-Received: from localhost ([::1]:37225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrulY-0001M1-HM for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Jul 2012 13:43:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrulU-0001Iw-Bv for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:43:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrulS-0002XK-O0 for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:43:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrulS-0002XG-Kl for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:43:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SrurS-0003jP-Ov for bug-gnu-emacs@gnu.org; Thu, 19 Jul 2012 13:50: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: Thu, 19 Jul 2012 17:50: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.134272018414307 (code B ref 11939); Thu, 19 Jul 2012 17:50:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 19 Jul 2012 17:49:44 +0000 Original-Received: from localhost ([127.0.0.1]:51137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Srur9-0003ii-Oe for submit@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:44 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:49597) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Srur7-0003ia-Je for 11939@debbugs.gnu.org; Thu, 19 Jul 2012 13:49:42 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6JHhRMN019105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Jul 2012 17:43:28 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6JHhQHN011379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 17:43:27 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6JHhQMn031564; Thu, 19 Jul 2012 12:43:26 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Jul 2012 10:43:26 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5007E46C.7030206@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac1lmwOyi4HyinGRQiG+loiJiua8XQAMggCA X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:62168 Archived-At: > > "Spawning child process: invalid argument > > No idea. Maybe this is the Powershell issue described in > http://tb-nguyen.blogspot.co.at/2010/05/how-to-fix-emacs-windo > ws-error-spawning.html > > I just checked on a SP3 machine and am sure that just > installing SP3 is not sufficient for the problem to show up. I do not have/use Powershell, AFAIK. But I see that my env var SHELL has the value "/bin/bash". That is no doubt the cause. > >> I still don't understand the consequences described in the > >> doc-string of `redirect-frame-focus' as > >> > >> A frame's focus redirection can be changed by `select-frame'. > >> If frame FOO is selected, and then a different frame BAR is > >> selected, any frames redirecting their focus to FOO > >> are shifted to redirect their focus to BAR. This allows focus > >> redirection to work properly when the user switches from one > >> frame to another using `select-window'. > > > > I think that last part means only that focus switches when > > you select a frame, even if the previously selected frame > > was not really selected but had the focus > > only via a redirection from the actually selected frame. > > It seems to say that when a frame X has focus redirected to > the selected frame A and I now select a frame B then focus > for X is redirected to B. But why is that useful? The reason given is to pass redirection on, when you switch to another frame. But I agree that it is not clear, and I too wonder about the usefulness. I would think that redirection should be a simple mapping from one frame to another. 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. > >> This means that a frame whose focus is redirected to itself is > >> treated differently from a frame whose focus is redirected to > >> nil; the former is affected by `select-frame', while > >> the latter is not. > > > > It does not say what does affect the latter. Not too clear to me. > > It seems to say that when a selected frame A's focus is > redirected to A itself and I now select frame B, focus from A is > redirected to B. Yes, I think it says that. And it says that a frame that is redirected to nil is not affected by select-frame. (It does not say what does affect a frame that is redirected to nil.) > 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? What are you envisioning? FWIW, the only redirection that I use (AFAIK) is to redirect my *Completions* (special-display) frame to the minibuffer frame. That seems to work just as I would expect - no problems. But nothing prevents you from explicitly selecting *Completions* and even trying to type input there, even when the minibuffer is active. But *Completions* is read-only, so if you do that you get a read-only error. For example, in the minibuffer, Icicle mode binds `C-insert' to a command that does (select-window (get-buffer-window "*Completions*" 0)). You can do various things there, but if you try to type a self-inserting char or delete a char then you get this error: "Buffer is read-only: #". > 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. But again, I have no idea whether (a) that is easy to do or (b) whether it is really a good idea to do it. > 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? > >> and hope that read_minibuf correctly redirects the prompt > >> to the minibuffer frame. > > > > My guess is that it does, always. > > Apparently not always as we know meanwhile. 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). 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. 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.) > > Again, my guess is that it did that > > correctly, but the new frame was then created (the > > creation might have started before the read_minibuf, but the > > new focus took effect after the redirection to > > the minibuffer, in any case). Just a guess. > > 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?