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 focuswhenit calls `list-processes' Date: Mon, 6 Aug 2012 14:05:38 -0700 Message-ID: <66AA74201A324E009E0D9D367E009A7B@us.oracle.com> References: <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> <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> 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 1344287182 18420 80.91.229.3 (6 Aug 2012 21:06:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Aug 2012 21:06:22 +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 Mon Aug 06 23:06:22 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 1SyUVD-0004EA-NA for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Aug 2012 23:06:16 +0200 Original-Received: from localhost ([::1]:41758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyUVC-0006m8-Ms for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Aug 2012 17:06:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyUV7-0006l1-Mp for bug-gnu-emacs@gnu.org; Mon, 06 Aug 2012 17:06:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyUV5-0003Ym-Fv for bug-gnu-emacs@gnu.org; Mon, 06 Aug 2012 17:06:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyUV5-0003Yg-Bl for bug-gnu-emacs@gnu.org; Mon, 06 Aug 2012 17:06:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SyUcj-0000Ek-JQ for bug-gnu-emacs@gnu.org; Mon, 06 Aug 2012 17:14:01 -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: Mon, 06 Aug 2012 21:14: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.1344287627884 (code B ref 11939); Mon, 06 Aug 2012 21:14:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 6 Aug 2012 21:13:47 +0000 Original-Received: from localhost ([127.0.0.1]:38146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUcS-0000E9-2O for submit@debbugs.gnu.org; Mon, 06 Aug 2012 17:13:47 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:37465) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyUcL-0000Dw-R7 for 11939@debbugs.gnu.org; Mon, 06 Aug 2012 17:13:42 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q76L5evE015769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 21:05:41 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q76L5ehh016997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2012 21:05:40 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q76L5etV006538; Mon, 6 Aug 2012 16:05:40 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Aug 2012 14:05:39 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac1z6DRCPYudJ+Y/R1mGFsweNpTYrgAFqPwg In-Reply-To: <501FE2DF.6030906@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:62887 Archived-At: > >> > Something like this: > >> > (with-unfocused-buffer-displayed BUFFER &body BODY) > >> > > >> > where BUFFER is displayed for information only, and where > >> > BODY would include the call(s) that read from the minibuffer. > >> > > >> > The current buffer would remain what it was beforehand, > >> > and _if_ BUFFER gets displayed in its own frame and _if_ > >> > there is a standalone minibuffer frame, _then_ the focus > >> > for BUFFER's frame gets automatically redirected to the > >> > minibuffer frame. > >> > >> In my experience, this requirement is met if the construct requests > >> input with BUFFER's window temporarily selected and BUFFER > >> temporarily current. Or am I missing something? > > > > Sorry, I don't know what that means. Perhaps give an > > example of what you mean by temporarily selected and current? > > Temporarily selected means selected via `with-selected-window' and > temporarily current means `with-current-buffer'. OK, but I still don't see what you are trying to say, or why. 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? 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. 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). 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). > >> > handling needed - the construct can essentially be a no-op > >> > in that case (AFAICT). > >> > > >> > How something like this would be implemented I'm not sure. > >> > When the redirection would need to take place, to DTRT, > >> > I'm not sure. Perhaps it would need to be done more than once. > >> > > >> > But an important further requirement is that nothing > >> > should prevent Emacs code in BODY or called from within > >> > BODY from switching the input focus to BUFFER's frame. > >> > >> I don't understand what BODY should contain. Would this macro be > >> responsible for displaying BUFFER? > > > > No, not as I was conceiving it. I suppose that would be a > > possibility, but I expect it is better to keep buffer display out of it. > > That's why I said things like "_if_ BUFFER gets displayed in its own frame". > > > > What I had in mind was that the macro would be responsible > > only for making sure that minibuffer input gets (re-)directed to the > > minibuffer frame. And that goes for any code in BODY, including code > > that might pop up BUFFER. > > > > IOW, display of BUFFER would come (if it came) from BODY. > > > > But again, I'm just thinking out loud. And it's probable > > that you see things that I do not. > > No. Just that I don't have the slightest idea how to write a > macro that modifies the behavior of a `yes-or-no-p' dialog it calls. > read_minibuf and the code for handling keyboard events do the redirecting. > > >> > Likewise, nothing should prevent the user from explicitly > >> > switching the focus to BUFFER's frame. > >> > >> This is part of the `yes-or-no-p' dialog, nothing within the scope > >> of the construct you propose. > > > > Can you elaborate? I don't follow. > > 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. I spoke of redirecting, but it might take more than that or doing that more than once, if the OS switches focus after redirection to the minibuffer. > > No. Again, during reading from the minibuffer it is quite > > possible for a user to interact with other buffers and their frames. > > I gave the example of *Completions*. The user can hit a key or use > > the mouse to change the input focus temporarily to another frame - > > any frame. > > > > When the user does that s?he is executing code within > > BODY. It is code that reads from the minibuffer, but also code > > that implements any commands bound to keys or mouse actions that > > the user uses during that minibuffer dialog. That's > > all I meant. > > I'm afraid this gets too complicated for me. You have to find someone > who understands such scenarios better than me. The scenario is as simple as your clicking a special-display (hence dedicated, separate frame) *Completions* frame during minibuffer input. That changes the focus to *Completions*. But that doesn't mean that you cannot switch back to the minibuffer frame again. The only point here is that whatever is done to fix the problem should not in any way prevent a user from clicking *Completions* and thus switching the focus there. Or any other frame, besides *Completions*. You should be able to click another frame, type some text there, then click the minibuffer frame and finish entering the input text it wants to read. IOW, minibuffer interaction is not modal; it does not (should not) prevent you from interacting with other parts of Emacs, including typing into other frames. This was in response to your statement that we wanted to _always_ have the focus on the minibuffer frame. 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. > >> > I do not expect that the problematic use case we've been > >> > discussing can be detected and dealt with correctly in an > >> > automatic way. If the programmer intention > >> > >> Who is the programmer here? > > > > The person who writes the code that reads from the minibuffer, > > code that might or might not be wrapped in the new macro, i.e., > > that might or might not want to stipulate that BUFFER is not to > > receive the input focus. > > The person who writes that code expects `yes-or-no-p' DTRT. Agreed. > >> I refer to the case where a minibuffer-equipped frame is > >> popped up. > > > > I'd rather you didn't. Let's not bring in new things. > > Users with non-nil `pop-up-frames' who don't use minibuffer-only > frames do get a minibuffer-equipped frame popped up. Of course they do. But is there a problem for them? Has any problem similar to the one reported for this bug been identified for those different use cases? This bug is about a problem that arises (with MS Windows) when you do have a standalone minibuffer frame. That's all. > You can ignore them, I can't. No one is asking you to ignore them. If you see a related problem for other use cases, by all means, try to address that problem at the same time. I have not heard of such a problem, so to me bringing up that use case seems irrelevant. I care about _this_ bug being fixed. But that does not mean that I want to prevent you from fixing other bugs. I haven't heard of any such problem without a standalone minibuffer, however. > And a user who excludes BUFFER from the list of specially > displayed buffers does a perfectly valid thing and can expect Emacs to > handle it as it currently does. OK by me. I have no argument against that. I don't see how it's related, but it's fine by me. > > I don't know. The only problems I am aware of for > > `w-t-b-w.el' are these: > > > > 1. Loss of special-displayness (a separate problem, but > > important if we're talking about `w-t-b-w.el' as it stands now). > > > > 2. The fact that it limits itself to display of temporary > > buffers, whereas the actual problem has to do with the temporary > > display of buffers. > > Because I can safely kill a temporary buffer and remove its frame when > I'm done with the dialog. OK. I've already agreed that that is a good thing. I'm in favor of your proposed fix. I was just pointing out that there can be cases of MS Windows messing things up that your fix won't solve, namely, temporary display of a non-temporary buffer, a buffer that you do not want input to be focused to. > > And as far as you know, is the fact that the minibuffer > > frame is still used (as it should be) due only to the fact that > > `yes-or-no-p' is used, or can I expect > > that the minibuffer frame will be used in general? > > Due to the fact that `yes-or-no-p' is called in a special way > - with the new window selected. > > >> >> `with-temp-buffer-window' avoids that by asking the > >> >> `yes-or-no-p' question in the new frame. > > > > Dunno why I (or was it you?) said that. I see the > > question in the minibuffer frame, not the new frame. > > Which is TRT. > > To "see the question in the minibuffer frame" I ask it in the > new frame. OK. That was worth clarifying. I wasn't understanding that. I see the question in the minibuffer frame, and I type the answer there. My impression was that the minibuffer frame had the focus. 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? 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? > > 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? > 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? > And I can't kill a non-temporary buffer. > > The informational frame? I'd vote for `delete-frame', at > > least for my own use. We might want to provide ways for the > > caller and/or the user to control both what to do with the > > frame/window and what to do with the buffer. But maybe > > `frame-auto-hide-function' would make sense here? > > 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.