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 when it calls `list-processes' Date: Sun, 15 Jul 2012 09:43:04 -0700 Message-ID: <6F73D04E8EE144E780D602DFEBA48E7B@us.oracle.com> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@gmx.at> <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> <5002EAF4.5080107@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 1342370659 13797 80.91.229.3 (15 Jul 2012 16:44:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2012 16:44:19 +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 15 18:44: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 1SqRve-0001Yq-Qb for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2012 18:44:19 +0200 Original-Received: from localhost ([::1]:59053 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqRvd-0000lv-SU for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2012 12:44:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqRva-0000lq-HY for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 12:44:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SqRvY-0006CB-QY for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 12:44:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqRvY-0006C7-NF for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 12:44:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SqS1B-0000Wo-Qv for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 12:50: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, 15 Jul 2012 16:50: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.13423709511961 (code B ref 11939); Sun, 15 Jul 2012 16:50:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 15 Jul 2012 16:49:11 +0000 Original-Received: from localhost ([127.0.0.1]:43004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqS0M-0000VY-S0 for submit@debbugs.gnu.org; Sun, 15 Jul 2012 12:49:11 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:48738) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqS0K-0000VR-8Q for 11939@debbugs.gnu.org; Sun, 15 Jul 2012 12:49:09 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6FGhGFY001171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jul 2012 16:43:17 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6FGhG4c012054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 16:43:16 GMT Original-Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6FGhFj5031791; Sun, 15 Jul 2012 11:43:15 -0500 Original-Received: from dradamslap1 (/10.159.181.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Jul 2012 09:43:15 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5002EAF4.5080107@gmx.at> Thread-Index: Ac1ipAh6znQ2XuxOSeySfmwrBBxL5gAABB3w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:61968 Archived-At: > >> Sorry. Do (defalias 'yes-or-no-p 'y-or-n-p) and then try. > > > > Are you sure you mean that? AFAIK, `y-or-n-p' is not at > > all representative - it does not even use the minibuffer, > > I think: it just reads events directly. I will try to do as > > you instruct, if you confirm, but I do not understand how > > using `y-or-n-p' here can possibly help. > > Because you can do `select-frame-set-input-focus' with it. I'm afraid I still do not understand (but maybe I don't need to). I thought the problem has to do with input focus for minibuffer reading. But maybe you are saying that the minibuffer need not be involved, and that `read-event' will also depend on which frame has the focus. In any case, please give me the specific recipe that you would like me to try. I'm afraid I've lost track at this point. And is this still pertinent, given what we have discovered wrt a reproducible recipe from emacs -Q? > >> ... what command is C-] bound to? I can't type it on my > >> keyboard ... > > > > `abort-recursive-edit'. `C-]' is the (only) default > > global binding (emacs -Q) for `abort-recursive-edit'. > > My keyboard doesn't allow me to input things like C-] easily > so I don't know what these do. You could rebind that command to see what it does. And `C-h f' describes it. (It is a bit like a super C-g.) > If you get the problem with `pop-up-frames' t and not with the special > display settings we have simplified the problem. Yes, greatly. > > A second bug (I think) is that there is NO feedback/response > > to your typing the answer. With focus in the *Process List* > > frame, which has a read-only buffer, I would expect an error > > message saying that the buffer is read-only. But you get > > NO message - nada. Not only that, but I see no such > > message in buffer *Messages* if I look there. Dunno why this is. > > I suppose that as long as you don't type either yes or no in the > original frame nothing happens at all. Presumably _some_ buffer receives the input. If it is a read-only buffer then I would expect a read-only error message. If it is not then I would expect to see what I type in some buffer. I see neither effect. And presumably (it seems that way anyway) it is the *Process List* buffer, which is read-only, that has the focus. This behavior does not seem normal. > > Well, that's one problem, anyway. Really, I do not want > > the new frame popped up to have a minibuffer and pose the > > question about killing processes. I want the > > new frame to just be displayed and _not selected_ for > > input/output (user interaction). I do not want it to have > > a minibuffer. > > But we must select a frame for answering the question. The frame for posing and answering all questions should be, as usual, the minibuffer frame. Aside from `read-event' etc., reading user input should use the minibuffer, and that means it should use the minibuffer frame. Looking at the C code for `yes-or-no-p' (Emacs 23.3), it clearly calls `read-from-minibuffer' (`Fread_from_minibuffer'), so it should use the minibuffer. The frame that should have the input focus for that prompt and reading should be the standalone minibuffer frame - that is the _only_ frame that has a minibuffer. It makes no sense for any other frame to have the input focus when reading from the minibuffer, since no other frame _has_ a minibuffer. > > More precisely, I don't have much of an opinion in the > > case of a non standalone minibuffer. > > > > But in the case of a standalone minibuffer, it definitely > > should continue to have the input focus. That's the point, for me. > > Why "continue"? You could invoke C-x C-c in any frame. See above. It should have the input focus for any _reading from the minibuffer_. Obviously, other frames can have the input focus when not reading from the minibuffer. `yes-or-no-p' reads from the minibuffer. > > It would not be a solution for me to give the new frame > > its own minibuffer or something and to let it keep the input > > focus. The user should be able to always look to the same, > > standalone minibuffer - the *only* minibuffer area - for all > > prompts and user replies. > > We'll see to that. That would be a great fix. > >> > Buffer *Help* is still popped up in a new frame that has > >> > those colors, but now when I hit `q' in it the frame does not > >> > disappear and its buffer is changed. That's not what I would > >> > call "dedicated" anymore. > >> > >> That's hardly surprising: With `pop-up-frames' t you > >> shouldn't get a dedicated window, I suppose. > > > > Uh, if you are saying what I think you are saying then I'm > > afraid I disagree strongly about that. To me, that would be > > a regression. > > Don't be afraid. I meant with `pop-up-frames' t and > `special-display-buffer-names' and friends nil. OK. But the behavior I saw with that test indicated/suggested that *Help* was not entirely special-display (with `pop-up-frames' t and the *Help* frame defined as indicated with `special-display-buffer-names'. The frame was created with the correct colors etc., but buffer *Help* ended up being replaced in the frame, which is not what "special display" means. So I think there might be a second bug here. > > If I use Dired+ (which does what my patch does) then there > > is no problem, so in my daily use this is solved for the > > Dired but reported, but not in general (viz. > > this bug wrt quitting with active processes). > > But your patch doesn't address the input focus issue or am I missing > something? Correct. But the problem does not exist with my patch. I don't have an explanation. But please see the #15566 thread - in particular, the part about the use of code that is nearly identical but that does not manifest the input problem. See the message I sent that has the attachment `throw-chmod-vs-chmod-rec.el'. I do not understand why what I report happens, but it happens. This is from that thread: >> But this is the same code sequence that occurs for `M' - >> AFAICT the only difference is the existence of the two >> preliminary questions. So it's not clear to me where the >> problem comes from. This is the calling sequence: >> >> dired-do-chmod OR diredp-do-chmod-recursive >> dired-mark-read-string >> dired-mark-pop-up >> dired-pop-to-buffer >> make-frame, then read-from-minibuffer (via FUNCTION arg) >> >> The code for `dired-do-chmod' and `diredp-do-chmod-recursive' >> is nearly identical - see attachment. The only difference is the >> gathering of the list of files (which includes the preliminary >> confirmation questions). But let's not worry about that here/now. Perhaps this thread will find a solution to the problem _in general_. That's my current hope, at least. > > If you want a standalone minibuffer frame to have the > > _only_ minibuffer then you must do everything at load time, > > i.e., in .emacs. > > So this makes debugging more difficult for people who are not used to > work with minibuffer-only frames. Yes. That's not my doing; it's a fact of GNU Emacs life. Unless someone provides a fix that changes this. > I have attached another version of `with-temp-buffer-window' which now > explicitly shifts input focus to the frame selected at the time the > macro is called. I hope this will fix the `pop-up-frames' t scenario. > I'm afraid it will not fix the problem when you invoke C-x C-c in any > window but the minibuffer-only window so we probably have to fix that > issue separately. Please try it. Just what is the recipe to try (e.g. from emacs -Q)? Wrt "C-x C-c in any window but the minibuffer-only window": It's about reading from the minibuffer (e.g. `read-from-minibuffer'). It never matters (apart from this bug about new frames that get created during the minibuffer reading) which buffer/frame is selected when you call `read-from-minibuffer'. Focus is always switched to the minibuffer (and its frame). The problem here seems to be that just after focus is correctly switched to the minibuffer frame, for minibuffer interaction (reading), the new frame is popped up and MS Windows gives it the focus. At least that's the (limited) conceptual model I'm adopting so far. IOW, I don't think the problem is to give the minibuffer frame the focus. I'm assuming that that is happening correctly, as usual. The problem, I think, is that the new frame creation happens at the same time or just afterward, and that steals the focus from the minibuffer frame (thanks to MS Windows). Thx - Drew