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: Sun, 29 Jul 2012 11:01:29 -0700 Message-ID: References: <500A8C0E.4040006@gmx.at><96A974694CF64567A3EAB85185AB3A5C@us.oracle.com><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> 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 1343584919 17164 80.91.229.3 (29 Jul 2012 18:01:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2012 18:01:59 +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 Sun Jul 29 20:01:59 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 1SvXoU-0002Io-HS for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 20:01:58 +0200 Original-Received: from localhost ([::1]:41999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvXoT-0002nU-VF for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 14:01:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvXoR-0002nM-Fc for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:01:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvXoQ-00068J-6I for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:01:55 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvXoQ-00068E-2G for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:01:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SvXvK-0001Ju-0W for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 14:09: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: Sun, 29 Jul 2012 18:09:01 +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.13435853375061 (code B ref 11939); Sun, 29 Jul 2012 18:09:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 18:08:57 +0000 Original-Received: from localhost ([127.0.0.1]:49049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvXvE-0001JZ-8E for submit@debbugs.gnu.org; Sun, 29 Jul 2012 14:08:56 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:21437) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvXvA-0001JP-0Y for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 14:08:53 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6TI1eEV022597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jul 2012 18:01:41 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6TI1dar019854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 18:01:40 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6TI1dJc015398; Sun, 29 Jul 2012 13:01:39 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Jul 2012 11:01:39 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50156DFE.6090807@gmx.at> Thread-Index: Ac1trMbBiJLAQy/TRGm2Cz9tNc+gdQAAflbA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:62575 Archived-At: > > After the command I am at top level. And I am in no way > > stuck in a minibuffer window. > > > > The problem is that the `current-buffer' is " > > *Minibuf-0*". That's all. > > So you mean you are at top level, the selected window is the > minibuffer window, its buffer is current, and you've never > seen such behavior. Is that a correct description of what you > experience? I think we're both probably getting a bit lost in all of the emails, especially with the lapse of time, different tries of different scenarios, and encountered side issues (e.g. crashes). I apologize for contributing to that. Here's the (current) issue and scenario. It uses my setup (with untweaked oneonone.el but also with the other libraries that I use). The only thing I've done differently than usual is to evaluate this sexp: (add-hook 'after-make-frame-functions (lambda (frame) (redirect-frame-focus frame (window-frame (minibuffer-window))))) I do M-x shell. Then I do C-x C-c. The `yes-or-no-p' prompt about active processes appears in the minibuffer. I type "no" into the minibuffer. So far so good. Things are perfectly normal now, and I am at top level (the minibuffer has exited normally). I then do C-x k. Because my setup automatically inserts the default value (what `M-n' gives), that buffer-name value is inserted in the minibuffer, waiting for me to hit RET to accept it or to edit it and then hit RET. 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. 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. 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. 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. 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-:'. So perhaps this is only a problem with (because of) `yes-or-no-p'. And perhaps there is nothing that can (or should?) be done about it. It is anyway a minor problem compared to the general problem that this bug report is about: loss of focus to the minibuffer frame. I hope we are now clear about this `C-x k' default-buffer problem. Dunno what can or should be done about it. It seems (to me, so far) to be a problem with `yes-or-no-p' (and perhaps some other functions?): In order to ask its question, `yes-or-no-p' not only redirects input focus to the minibuffer but it also (apparently) selects the minibuffer's buffer. And it apparently leaves that buffer selected, as the `current-buffer'. 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 above behavior description holds for all Emacs versions I have. The `add-hook' solves the unfocused minibuffer frame problem for all versions. 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. 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?