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 whenit calls `list-processes' Date: Sun, 29 Jul 2012 15:55:28 +0200 Message-ID: <501540D0.50900@gmx.at> References: <5007E47B.3050907@gmx.at><446B437450EC47968D15C20D7142296B@us.oracle.com><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> 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 1343570160 25669 80.91.229.3 (29 Jul 2012 13:56:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 Jul 2012 13:56:00 +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 Sun Jul 29 15:56:00 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 1SvTyR-0007Js-D2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 15:55:59 +0200 Original-Received: from localhost ([::1]:33611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvTyQ-000768-RI for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jul 2012 09:55:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvTyO-000763-P7 for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 09:55:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvTyN-00053Z-Hq for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 09:55:56 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvTyN-000538-EH for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 09:55:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SvU5G-0004GD-Ev for bug-gnu-emacs@gnu.org; Sun, 29 Jul 2012 10:03: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: Sun, 29 Jul 2012 14:03: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.134357057216360 (code B ref 11939); Sun, 29 Jul 2012 14:03:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 29 Jul 2012 14:02:52 +0000 Original-Received: from localhost ([127.0.0.1]:48825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvU55-0004Fo-4l for submit@debbugs.gnu.org; Sun, 29 Jul 2012 10:02:51 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:50052) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SvU52-0004Ff-Oo for 11939@debbugs.gnu.org; Sun, 29 Jul 2012 10:02:49 -0400 Original-Received: (qmail invoked by alias); 29 Jul 2012 13:55:40 -0000 Original-Received: from 62-47-44-164.adsl.highway.telekom.at (EHLO [62.47.44.164]) [62.47.44.164] by mail.gmx.net (mp039) with SMTP; 29 Jul 2012 15:55:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18YQXMPa5MYjWdESznsb0OiumCxqxFyb2YKlNiemT QJ8FysCCO9qORU In-Reply-To: <4FB29D967D524DA99545D98266DD74B4@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:62562 Archived-At: > Well, OK. But normally, after the input is read the selected window/frame > returns to what it was before the reading. No? I don't know. read_minibuf does (my remarks appear below the code): /* Choose the minibuffer window and frame, and take action on them. */ choose_minibuf_frame (); record_unwind_protect (choose_minibuf_frame_1, Qnil); I don't understand the last two calls, IMHO one of them seems redundant. record_unwind_protect (Fset_window_configuration, Fcurrent_window_configuration (Qnil)); I don't know which frame is selected here in your case. /* If the minibuffer window is on a different frame, save that frame's configuration too. */ mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window)); if (!EQ (mini_frame, selected_frame)) record_unwind_protect (Fset_window_configuration, Fcurrent_window_configuration (mini_frame)); But this should restore the configuration of your minibuffer frame. I don't have the slightest idea whether and how the selected window is preserved provided it's on another frame. You could try checking via `minibuffer-setup-hook' and `minibuffer-exit-hook' but I'm afraid the latter is executed too early and you're still in the same state of affairs as in the setup hook. Are you stuck in the minibuffer window even when you do `top-level'? > The problem is (apparently) that the minibuffer buffer remains selected after > the reading, i.e., the (current-buffer) is " *Minibuf-0*". Thus, a subsequent > command such as `C-x k' sees that buffer as the current one. That has not > happened before - it seems to come as a result of redirecting the frame focus, > but perhaps that is just a catalyst/revealer. If this were the case, we'd have a bug. But the code doesn't indicate that. martin