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: Fri, 27 Jul 2012 08:33:14 +0200 Message-ID: <5012362A.7070200@gmx.at> References: <5006E14B.3000407@gmx.at><47731CC5C6EC4ED9AB9E9E05E259572C@us.oracle.com><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> 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 1343370906 13392 80.91.229.3 (27 Jul 2012 06:35:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2012 06:35:06 +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 Fri Jul 27 08:35:04 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 1Sue8a-0000Cg-C8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jul 2012 08:35:00 +0200 Original-Received: from localhost ([::1]:56402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sue8Z-0000Xu-Jm for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jul 2012 02:34:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sue8S-0000Tf-RK for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 02:34:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sue7k-00078E-0X for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 02:34:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sue7j-000784-T9 for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 02:34:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SueEP-0004Zj-Te for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 02:41: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: Fri, 27 Jul 2012 06:41: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.134337122017524 (code B ref 11939); Fri, 27 Jul 2012 06:41:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 27 Jul 2012 06:40:20 +0000 Original-Received: from localhost ([127.0.0.1]:42696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SueDi-0004YZ-59 for submit@debbugs.gnu.org; Fri, 27 Jul 2012 02:40:19 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:46614) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1SueDf-0004YO-8I for 11939@debbugs.gnu.org; Fri, 27 Jul 2012 02:40:17 -0400 Original-Received: (qmail invoked by alias); 27 Jul 2012 06:33:18 -0000 Original-Received: from 62-47-33-200.adsl.highway.telekom.at (EHLO [62.47.33.200]) [62.47.33.200] by mail.gmx.net (mp033) with SMTP; 27 Jul 2012 08:33:18 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18kHHQdZT4kGAl/mBDloeoUBVzoeBZZZ8jOy7uQNz K3nMxEjQSRc/dk In-Reply-To: <2F76545DBD0C4F199A60F4B750709112@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:62446 Archived-At: >> I see. But then where do you see a problem if your function prompts >> with the current buffer for killing? > > In the scenario I described - see my previous descriptions, but here is a > summary of what I did (before): > > C-x C-c, reply "no" > > C-x k, with the default being *shell* (even though frame *Process List* was on > top and had its title bar highlighted). Reply "yes" to killing the processes. > > C-x k, wanting to kill *Process List* - see previous descriptions for the > problems here. > > But in the latest test, where I did only the `redirect-*', the default buffer to > kill was ALWAYS " *Minibuf-0*". It's not a problem, in the sense that focus is > at least in the minibuffer frame and I can therefore choose not to use the > default. (In my setup, I automatically have the default inserted in the > minibuffer, but I can easily remove it.) I don't know what your C-x k does so I can't comment on it. The fact that `call-interactively' calls `other-buffer' when the selected window is the minibuffer window indicates that such a thing may happen and it will happen, for example, when I'm in the minibuffer and do M-:. >> Do you ever want to kill the minibuffer's buffer? > > No, never. > >> If not, your function should provide an >> appropriate workaround default just as `call-interactively' does. > > Well OK, I suppose - I can certainly try to do that. > > But I have never had to do it before. Obviously, if the right thing to do is to > work around this hiccup then I can and might try to do that. And as I said: ... as long as you can't tell me how you got into this hiccup ... >>>> Or as a workaround I can explicitly select the frame of the >>>> buffer I want to kill - e.g., click the title bar of frame *shell*. >>>> After I do that, that buffer becomes the default value for C-x k. > > But the point was that the minibuffer buffer was the (current-buffer) here, > suggesting to me that the minibuffer frame (and its buffer) was selected. > > Is that TRT? I didn't think so. I didn't think that just calling `redirect-*' > would/should also select the frame and its buffer. That is why I said this: Just calling `redirect-*' does not select the frame and its buffer. But `yes-or-no-p' does since otherwise you won't be able to type into the minibuffer - here's the relevant piece in read_minibuf: /* Display this minibuffer in the proper window. */ Fset_window_buffer (minibuf_window, Fcurrent_buffer (), Qnil); Fselect_window (minibuf_window, Qnil); XWINDOW (minibuf_window)->hscroll = 0; >>>> IOW, it seems that not only is the input focus redirected >>>> to the minibuffer frame, but also the current buffer is >>>> changed to *Minibuf-0*. And if I do `M-: >>>> (current-buffer)' I do get *Minibuf-0*. Is it normal for >>>> frame-focus redirection to change the current buffer also? >>>> That does not seem right to me. > > None of that has to do with my `C-x k' command, I believe. AFAIK, I do not > select the minibuffer frame or buffer. I speculated that perhaps the C code for > read-from-minibuffer does, but I don't know that. See above. martin