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 focuswhenit calls `list-processes' Date: Tue, 07 Aug 2012 10:58:30 +0200 Message-ID: <5020D8B6.5000701@gmx.at> References: <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> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> <501D2755! .3030500@gmx.at> <75CAF22BF973452CB85EFC802F2C171A@us.oracle.com> <501! FE2DF.6030906@gmx.at> <66AA74201A324E009E0D9D367E009A7B@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 1344329961 19114 80.91.229.3 (7 Aug 2012 08:59:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Aug 2012 08:59:21 +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 Tue Aug 07 10:59:19 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 1SyfdF-0007K6-8U for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Aug 2012 10:59:17 +0200 Original-Received: from localhost ([::1]:33944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyfdE-00023G-CE for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Aug 2012 04:59:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyfdB-0001wv-8k for bug-gnu-emacs@gnu.org; Tue, 07 Aug 2012 04:59:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Syfd3-00046n-Vs for bug-gnu-emacs@gnu.org; Tue, 07 Aug 2012 04:59:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Syfd3-00046j-S9 for bug-gnu-emacs@gnu.org; Tue, 07 Aug 2012 04:59:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Syfkl-00056M-0f for bug-gnu-emacs@gnu.org; Tue, 07 Aug 2012 05:07:03 -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: Tue, 07 Aug 2012 09:07: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.134433038619554 (code B ref 11939); Tue, 07 Aug 2012 09:07:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 7 Aug 2012 09:06:26 +0000 Original-Received: from localhost ([127.0.0.1]:38802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Syfk9-00055K-Hp for submit@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:26 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:47536) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Syfk7-00055D-B2 for 11939@debbugs.gnu.org; Tue, 07 Aug 2012 05:06:24 -0400 Original-Received: (qmail invoked by alias); 07 Aug 2012 08:58:25 -0000 Original-Received: from 62-47-37-156.adsl.highway.telekom.at (EHLO [62.47.37.156]) [62.47.37.156] by mail.gmx.net (mp041) with SMTP; 07 Aug 2012 10:58:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/Mx4YeBFnMuwpnGD7HkMjsc/NrN+WePcyc3up0Rd 97tC9dQClNz2PP In-Reply-To: <66AA74201A324E009E0D9D367E009A7B@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:62906 Archived-At: > You seem to be saying that if BUFFER is selected/current, and if input is read > somewhere (where?) - then what? The focus gets automatically redirected to the > minibuffer frame? A BUFFER is not selected, only a window or a frame is. I say that when a window on a minibuffer-less frame is selected and its buffer is current at the time a `yes-or-no-p' question is asked, focus for reading input from the minibuffer gets redirected to a minibuffer-equipped frame. > This is not about reading input with BUFFER selected/current. The idea is to > have the _previously_ selected buffer be selected/current, while input is read > from the minibuffer. The idea is not to make BUFFER selected/current, but just > to display it. I don't talk about ideas. I talk about the current implementation of dialogs that read text from the minibuffer. > Beyond that, that sentence of mine was shorthand. It (apparently) is not enough > that the focus be redirected once, at some point, to the minibuffer frame. It > needs to either remain there (somehow preventing MS Windows from moving it away) > or be put back there (after MS Windows moves it to BUFFER's frame). Focus redirection is done by Emacs. MS Windows won't redirect focus. > IOW, even > if redirection is happening now as it should, it is not sufficient if, after > that redirection to the minibuffer, the OS changes the focus again (to the new > frame). Any redirection is permanent for a frame until it's explicitly changed by Emacs. >> IIUC you want to modify the behavior of `yes-or-no-p' to >> redirect frame focus in your sense. > > I don't know why you mention `yes-or-no-p'. This is about reading from the > minibuffer, in general. > > I don't want or not want to modify `yes-or-no-p' or `read-from-minibuffer'. I'm > just saying that if the problem is that we want to display BUFFER, and it gets > displayed in a new frame, and we want to read from the minibuffer, then we do > not want, for that minibuffer reading, the input focus to be in BUFFER's frame. Above you say that > It (apparently) is not enough > that the focus be redirected once, at some point, to the minibuffer frame. so you want to modify `yes-or-no-p' or `read-from-minibuffer'. > Yes, when reading from the minibuffer is initiated, > the minibuffer frame should get the focus. But the user (or Emacs) should not > be prevented from switching the focus to another frame. > > All that we are trying to prevent or remedy is the focus switching to another > (new) frame by the OS. We should not be preventing either Emacs or the user > from switching focus to another frame, just because the minibuffer is active. > > That is the only point I was trying to make here. And my point is that beyond the initial redirection the mechanism reading keyboard events is responsible for providing such behavior. > I did not know where you were asking the question. By that, I assume you mean > that the new frame is selected (and has the focus?) when you invoke > `yes-or-no-p'. Is that right? I temporarily select the new frame when I invoke `yes-or-no-p'. The new frame will be selected again by `handle-switch-frame' if and when Emacs is notified by the OS. > Just for my info, why does it matter where `yes-or-no-p' is invoked? _Should_ > it matter, or is it just a fact that we must live with that it does matter? It does matter if and when the selected frame does not have a minibuffer and I want to redirect focus to a minibuffer frame. >> > Yes, it is more restrictive than the actual problem encountered. >> > As I said, it might suffice in practice, but there is nothing in the >> > problem description that requires that the buffer itself be temporary. >> >> I have to kill the buffer to remove the frame. > > I don't understand why, but probably I don't need to understand everything. Why > doesn't `delete-frame' do what you need? Because the window is "quit" when the user is done with the dialog. `quit-window' deletes the frame only if the buffer is killed or `frame-auto-hide-function' takes over. >> And I have to remove the frame because you complained that >> `save-window-excursion' cannot remove a popped up frame. > > Hm. I don't recall that at all, but I believe you that I did. Was that in some > other thread? In the thread on the behavior of `dired-mark-pop-up' IIRC. >> If we use `frame-auto-hide-function', the caller does not have to kill >> the buffer and there's no need to make this construct work >> for temporary buffers only. > > That sounds good to me. Perhaps I'm missing something. I don't want to steer > you down the wrong path, but what you say here sounds good to me. > > If the more general case can be handled, then the more restrictive case > (temporary buffer, not just temporary display) could presumably be handled also, > as a subcase, no? Or even if not as a subcase, as a separate case. > > IOW, if possible it would be good to have both possibilities, so a programmer > could get the right behavior for a given context: If s?he wants that buffer to > be temporary, then call a construct that treats it as such (killing it). If > s?he wants that buffer not to be temporary and only its display to be temporary > then call a construct that does that instead. > >> > Anyway, let's talk about this later. >> >> It's your choice. > > Can we have both possibilities? > > If not, let's get the temporary-buffer one first. IOW, I think you have that > case almost nailed - there is just the special-display/dedicatedness that does > not work yet. Then have a look at what happens there. martin