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 08:06:47 -0700 Message-ID: <893E59C2E4F94D6EB910560C9E8C42CD@us.oracle.com> References: <500173A5.3040608@gmx.at> <1986D90E22154321A44B6E0110CA4F5A@us.oracle.com> <50019C2F.8060103@gmx.at> <6B9036DBFDEF4881AB39804520BF63B3@us.oracle.com> <5002BEC6.3040106@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 1342364842 1535 80.91.229.3 (15 Jul 2012 15:07:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2012 15:07: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 Sun Jul 15 17:07: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 1SqQPo-0000lv-0F for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2012 17:07:20 +0200 Original-Received: from localhost ([::1]:46274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqQPn-0006R4-68 for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2012 11:07:19 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqQPi-0006Qo-Pt for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 11:07:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SqQPg-00006K-TW for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 11:07:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SqQPg-00006F-PA for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 11:07:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SqQVJ-0006mx-S8 for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2012 11:13: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: Sun, 15 Jul 2012 15:13: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.134236517526083 (code B ref 11939); Sun, 15 Jul 2012 15:13:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 15 Jul 2012 15:12:55 +0000 Original-Received: from localhost ([127.0.0.1]:42943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqQVC-0006mc-N4 for submit@debbugs.gnu.org; Sun, 15 Jul 2012 11:12:55 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:29830) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SqQVA-0006mR-BD for 11939@debbugs.gnu.org; Sun, 15 Jul 2012 11:12:53 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6FF71HZ019157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jul 2012 15:07:02 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6FF70iF008582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jul 2012 15:07:00 GMT Original-Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6FF70kJ031512; Sun, 15 Jul 2012 10:07:00 -0500 Original-Received: from dradamslap1 (/10.159.181.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 15 Jul 2012 08:06:59 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5002BEC6.3040106@gmx.at> Thread-Index: Ac1iib3rnASF21esQ6yH2C6IU4ad4AAB8RZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:61962 Archived-At: Hi Martin, > >> OK. What happens if in in `yes-or-no-p' you use > >> (when minibuffer-auto-raise > >> (select-frame-set-input-focus > >> (window-frame (minibuffer-window)))) > >> instead of `raise-frame'? > > > > Sorry, I don't understand. `yes-or-no-p' is coded in C. > > Where should I change a call to raise-frame to instead use the above code? > > 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. > ... 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'. > > OK, I tried that: still using my setup, I set > > `special-display-regexps' to nil then tried C-x C-c etc. > > > > That changed nothing (except that the popped up buffer > > appeared in a regular frame, not a special-display frame). > > The symptoms were identical AFAICT: input > > did not go to minibuffer, and quitting (C-]) left the > > frame but put the originally current buffer in it, replacing the > > processes-list buffer there. > > But it does work with emacs -Q on your system, I suppose? I'm not sure just what the test was to be here. But I tried with emacs -Q (plus loading cygwin-mount.el & setup-cygwin.el, so that I have a bash shell on Windows). I tried first with nil `pop-up-frames' - that behaved normally, i.e., as it should. I tried then with non-nil `pop-up-frames' - and that manifested the same problem that I reported! Good news! So even *without* a standalone minibuffer and the rest of my setup, this bug is reproducible. Thanks for helping find that. (Perhaps there are additional problems, but we need not worry about those now, if any in fact exist.) So that's great news. A simple recipe: 1. On MS Windows (I'm using XP SP3). (I hope someone on Windows will confirm and help.) 2. emacs -Q 3. Load cygwin-mount.el, then setup-cygwin.el (from Emacs Wiki's Elisp Area). 4. M-x set-variable pop-up-frames t 5. M-x shell 6. C-x C-c The informative buffer *Process List* is popped up in a separate frame, which apparently gets the focus. The question about killing active processes appears in the minibuffer of the original frame (which has only buffer *shell*). Because the new frame has the focus, _you cannot answer the question_. You are forced to select the frame with the question (e.g. clicking mouse-1 on its title bar), in order to answer it and exit Emacs. 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. > So the problem seems that input doesn't get redirected to your > minibuffer frame when popping up a new minibuffer-less frame. Seems to not depend on a standalone minibuffer frame, but yes, that seems to be the problem. 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. 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. 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. > > Oh, it also changed this: Now when I hit `q' in *Help*, > > instead of the frame being removed I get another buffer in it, > > substituted for *Help*. This in spite of the fact that > > `special-display-buffer-names' has this entry, which should > > make *Help* be dedicated: > > > > ("*Help*" 1on1-display-*Help*-frame > > ((background-color . "Thistle") > > (mouse-color . "Blue Violet") > > (cursor-color . "Blue Violet") > > (height . 40))) > > > > 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. If a buffer is declared via `special-display-buffer-names' to be special-display, then it _must be_ special-display. That must not be violated just because `pop-up-frames' might have some particular value. I *hope* I am just misunderstanding you here - I hope you are not suggesting that `special-display-buffer-names' is no longer enough to ensure that a buffer is special-display. > >> BTW, has bug#11566 been resolved meanwhile? > > > > Not at all (not that I know of/can tell). The last message in > > that thread is from me, and its questions were never answered. > > Then why do you suggest at the beginning of the current thread to > > >> "look to `dired-mark-pop-up' which does something similar > >> but gets it right" > > if it apparently doesn't get it right anyway? I'm sorry; I was probably confused in saying that. I must have meant that it works with the patch I sent, which (I thought) was applied to Emacs (or was going to be applied). 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). > It would be fine if we were able to sketch the problem as > follows: If a user has a > > (1) minibuffer-only frame and all other frames use that minibuffer and > (2) a `yes-or-no-p' or `read-from-minibuffer' prompt pops up in a > separate frame > > then `select-frame-set-input-focus' is needed to redirect > input to that minibuffer-only frame inorder to answer the question. See above. What you say might well be involved (i.e., be part of a solution), but the problem (of this bug) is apparently present even without a standalone minibuffer frame. > Can't you try to provide a test example on this basis? I don't know how. I did suggest in the bug #11566 thread that perhaps `read-from-minibuffer' could do something like that systematically, and I thought briefly that I had found a general solution that way, but I soon discovered that `message' then had no effect! No messages were ever output if I did that. > The Elisp manual doesn't help me at all when I try doing that. > For example, if I want to know how to use `set-minibuffer-window' > for setting up the minibuffer-window to use for > a minibuffer-less frame, I'm completely lost. I'm sorry I can't help either, here. I know less about this than you do - especially wrt Emacs windows, for which you are the expert. > If with emacs -Q I do > (let ((frame-1 (make-frame '((minibuffer . only)))) > (frame-2 (make-frame '((minibuffer . nil))))) > (set-minibuffer-window (frame-root-window frame-1))) > > then I still can't delete the initial frame because the > minibuffer-window for frame-2 is that of the initial frame. Ah, there I can help, in a minimal way at least, by confirming. I don't know why, and I cannot really explain anything here, but yes: If you want a standalone minibuffer frame to have the _only_ minibuffer then you must do everything at load time, i.e., in .emacs. That is why I have provided bug-repro recipes in the past that used this: runemacs.exe -Q -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs" Command `1on1-emacs' must be run before the initial frame is created. Otherwise, there will be a frame that has its own minibuffer, and you will never be able to get rid of that frame (as you discovered). IOW, it is too late to create your standalone minibuffer, once Emacs has already created a frame with a normal minibuffer. Whether this SHOULD be the case I cannot answer, but it has always been the case with Gnu Emacs, AFAIK. That is why I tell users of oneonone.el that they must do this: (require 'oneonone) (1on1-emacs) rather than just invoke `1on1-emacs' after Emacs has already created its initial frame, e.g., `M-x 1on1-emacs'. With the simple reproducible test case above, we are making real progress. I hope we can finally find a solution to this problem. My guess is that it lies at the root of a majority of the problems I've had with GNU Emacs and frames - problems that I have been trying to work around for decades. FWIW: Many Moon Ago, I used Epoch, which offered, out of the box, the ability to have a standalone minibuffer frame (they did not call it that), which stretched across the bottom of your display (by default). (No customization necessary - maybe you used a command switch when invoking the editor, I don't recall.) I found that to be a wonderful, simple, reasonable way to interact with Emacs (yes, Epoch was as much Emacs as GNU Emacs is). And I tried to reproduce that behavior in GNU Emacs. I've come close, but this problem, in particular, has always plagued me to some extent in my attempts.