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 whenit calls `list-processes' Date: Wed, 1 Aug 2012 09:34:50 -0700 Message-ID: References: <500BBE6F.6020007@gmx.at><1403DD3D67534F53BC023CC99A258DF5@us.oracle.com><838veb209m.fsf@gnu.org> <83r4s2zcp9.fsf@gnu.org><81CFBB36FDCB4CD6B3762F9E00AC8290@us.oracle.com><83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org> <83629blssa.fsf@gnu.org> ! <5011116B.4010106@gm x.at> <32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com> <50116AD9.706 09@gmx.at> <548032D12CE14E3689257D609E93482F@us.oracle.com> <501175C9.3090803@gmx.at> <2F76545DBD0C4F199A60F4B750709112@us.oracle.com> <5012362A.7070200@gmx.at> <4FB29D967D524DA99545D98266DD74B4@us.oracle.com> <501540D0.50900@gmx.at> <9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com> <50156DFE.6090807@gmx.at> <50165031.50905@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 1343838945 7208 80.91.229.3 (1 Aug 2012 16:35:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2012 16:35:45 +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 Wed Aug 01 18:35:45 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 1Swbtg-0007Ld-J3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Aug 2012 18:35:44 +0200 Original-Received: from localhost ([::1]:53373 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swbtf-0002Qn-QO for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Aug 2012 12:35:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swbtb-0002Qb-6i for bug-gnu-emacs@gnu.org; Wed, 01 Aug 2012 12:35:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwbtZ-0002HQ-AS for bug-gnu-emacs@gnu.org; Wed, 01 Aug 2012 12:35:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwbtZ-0002H4-6V for bug-gnu-emacs@gnu.org; Wed, 01 Aug 2012 12:35:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Swc0k-0007Kf-9S for bug-gnu-emacs@gnu.org; Wed, 01 Aug 2012 12:43: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: Wed, 01 Aug 2012 16:43: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.134383934828140 (code B ref 11939); Wed, 01 Aug 2012 16:43:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 1 Aug 2012 16:42:28 +0000 Original-Received: from localhost ([127.0.0.1]:55032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Swc0B-0007Jn-Qb for submit@debbugs.gnu.org; Wed, 01 Aug 2012 12:42:28 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:24132) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Swc08-0007JZ-FZ for 11939@debbugs.gnu.org; Wed, 01 Aug 2012 12:42:25 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q71GYrBL031726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 16:34:57 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q71GYpUv017771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 16:34:52 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q71GYpi5008643; Wed, 1 Aug 2012 11:34:51 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Aug 2012 09:34:50 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50165031.50905@gmx.at> Thread-Index: Ac1uM4gj6fbjIjzvTAKWsBJ1byGt1gBy9c2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:62719 Archived-At: > What does M-n do? M-n is standard Emacs in the minibuffer: it retrieves (inserts) the default value provided to the minibuffer-reading function (e.g. `completing-read'). (And starting with Emacs 23 you can repeat M-n to cycle among multiple default values.) > > The default buffer name in this case is " *Minibuf-0*". > > That is what I have never seen before. I.e., without adding that > > `add-hook' sexp (above), I do not get this behavior. > > I understand. Then we have to look at the command M-n is bound to. It inserts the default value. In this case, the default value is the value of (current-buffer), as I explained. The problem/mistake is that with the `add-hook' the value of (current-buffer) is now buffer " *Minibuf-0*". > > But I am not in any way trapped in the minibuffer. I can > > edit the buffer name to kill the buffer I want. Or I can hit C-g. > > And so on. > > But, apparently, whatever you do, the current buffer is still > *Minibuf-0*. Yes. (current-buffer) should not be *Minibuf-0*. (But (current-buffer) is only the default value, so I can still use `C-x k' here, by ignoring the default.) > > The only problem is that the value of `(current-buffer)' > > is " *Minibuf-0*" at that point. I know that by testing with > > `message' etc. That is why I hypothesized that something in that > > frame focus redirection caused the buffer " *Minibuf-0*" to become > > selected, i.e., the `current-buffer'. > > > > But you corrected me, pointing out that `yes-or-no-p' does > > that: it selects the minibuffer window/buffer. > > Let me try to correct this again: `yes-or-no-p' selects the minibuffer > window. `redirect-frame-focus' does not select any window. I don't > know how this is related to your problem. That is what I understood. > > If I do not do the `add-hook', then I cannot type yes/no > > to the `yes-or-no-p' prompt, without first manually selecting > > the minibuffer frame (e.g. by clicking its titlebar). And if I do > > that then the symptoms are the same as when I use the `add-hook': > > after typing "no", if I use C-x k then " *Minibuf-0*" is the > > default buffer to kill. > > where C-x k is not bound to `kill-buffer' but to another function Correct. Same scenario, still. > > But if (I do not do the `add-hook' and) I do `M-: > > (yes-or-no-p "Foo? ")' and I answer "no", then `C-x k' uses > > another buffer (the one selected before the M-:) as the default > > value. I am not sure why this difference, i.e., why > > `yes-or-no-p' does not leave " *Minibuf-0*" as the current > > buffer in this case. But it probably has to do with the > > execution of command `M-:' - IOW, in that test it is not just > > `yes-or-no-p' that is involved, but also `M-:'. > > `eval-expression' does consider the minibuffer window selected when > it's called from within the minibuffer. Doing C-h f and then C-: > (selected-window) RET will print the minibuffer window. Right (but M-:, not C-:). > > You know better than I what, if anything could/should be > > done to correct this. Should `yes-or-no-p' use > > `with-current-buffer' or something, so that it finishes > > by selecting again the buffer that was selected when it > > started? I'm guessing yes, but I know nothing about the code. > > It seems wrong that it should change the selected buffer to the > > minibuffer and leave it so changed. > > The code that does the selection and the restoration is in > read_minibuf which `yes-or-no-p' calls. As explained earlier, I don't > understand that code well enough in order to tell what to change. OK. I, even less, obviously. But at any rate, this wrong-buffer problem is minor. I don't want it to sidetrack us too much. The bigger issue is to have code somehow DTRT so that minibuffer interaction that is coupled with the popup of an informational-only window/frame, keeps the focus in the minibuffer frame. IOW, come up with some construct that lets code identify a particular minibuffer interaction as one that should keep the focus in the minibuffer frame. "Keep" here might mean redirect to the minibuffer if something outside Emacs and outside the user moves the focus away from it. And that "outside Emacs and outside the user" would be key, if we could in fact detect it. IOW, Emacs code can only say that some interaction should keep the focus in the minibuffer frame (or not, depending on what's intended). Emacs cannot prevent MS Windows or whatever from changing the focus. And we would want the user to be able to change the focus explicitly (during the minibuffer interaction), of course. > > The above behavior description holds for all Emacs versions I have. > > The `add-hook' solves the unfocused minibuffer frame problem > > for all versions. Again, I was wrong about that (e.g. *Backtrace* case). There are some cases where the minibuffer is active and a frame is popped that is not merely informational but should in fact receive the input focus. > > That means also that for Emacs 24 I do not need to use the > > `with-temp-buffer-window.el' code you sent. It is sufficient to > > use the `add-hook'. Dunno whether that helps you decide something > > for Emacs 24. > > The code has to work without any additional setup. Of course. I meant only that perhaps the equivalent of what I did in the hook might be something to do in general. I'm now backtracking on that because doing that systematically is not the panacea that I thought it might be. > > Given the info above, do you think that the equivalent of > > that `add-hook' should perhaps be built into Emacs? IOW, is some > > code correction in order, to do systematically what the `add-hook' > > workaround accomplishes? > > I don't know, unfortunately. The answer is no, because I said "systematically", and that is not TRT (e.g. *Backtrace*).