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'losesminibufferfocuswhenitcalls`list-processes' Date: Tue, 14 Aug 2012 07:36:45 -0700 Message-ID: References: <50165035.409040 1@gmx.at><501BAAB0.1020!807@gmx!.at><6461CCBF2903416 0B48D267E46D6FF0E@us.oracle.com><501D275D.3000701@gmx.at><7E4F337C7F6A4B8281!ABE6C82A8CA70E@us.ora cle.com><501FE2D4.1 050103@gmx.at><559D41024BC44EAC92C09DC14E1B7362@us.oracle.com><5022103E.6060502@gmx.at><72C02B3C324744308FB2DF605F46CCA3@us.oracle.com> <502378A8.90!10707@gmx.at> <5026266! 6.2060809@gmx.at> <502!785DF.1040200@gmx.at> <5028! A8FD.60705@gmx .at> < EE0A8E04D35647FE8CAAC52A84777A82@us.oracle.com> <502! A160E.5040601@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 1344955060 18746 80.91.229.3 (14 Aug 2012 14:37:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2012 14:37:40 +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 Tue Aug 14 16:37:41 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 1T1IFY-0001xt-Hm for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Aug 2012 16:37:40 +0200 Original-Received: from localhost ([::1]:39274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1IFX-0006gy-Do for geb-bug-gnu-emacs@m.gmane.org; Tue, 14 Aug 2012 10:37:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1IFP-0006fZ-De for bug-gnu-emacs@gnu.org; Tue, 14 Aug 2012 10:37:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1IFH-00039l-TM for bug-gnu-emacs@gnu.org; Tue, 14 Aug 2012 10:37:31 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1IFH-00039X-Pz for bug-gnu-emacs@gnu.org; Tue, 14 Aug 2012 10:37:23 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T1INd-0005or-KG for bug-gnu-emacs@gnu.org; Tue, 14 Aug 2012 10:46: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: Tue, 14 Aug 2012 14:46: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.134495553422215 (code B ref 11939); Tue, 14 Aug 2012 14:46:01 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 14 Aug 2012 14:45:34 +0000 Original-Received: from localhost ([127.0.0.1]:56408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1INB-0005mG-GS for submit@debbugs.gnu.org; Tue, 14 Aug 2012 10:45:34 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:26222) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T1IN9-0005m8-1J for 11939@debbugs.gnu.org; Tue, 14 Aug 2012 10:45:32 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7EEaoN7013998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Aug 2012 14:36:50 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7EEan9M016033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2012 14:36:50 GMT Original-Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7EEanUj014792; Tue, 14 Aug 2012 09:36:49 -0500 Original-Received: from dradamslap1 (/10.159.223.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Aug 2012 07:36:49 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac15/KdZUv81ALbYSnKdqgo8pN6IEQAJzfyQ In-Reply-To: <502A160E.5040601@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:63151 Archived-At: > > (save-selected-window > > (select-window (minibuffer-window)) > > (one-window-p nil 'selected-frame)) > > Any reason why you don't use > (one-window-p nil (window-frame (minibuffer-window))) > here? The doc for `one-window-p', for Emacs < 24, says this: "If ALL-FRAMES is neither nil nor t, count only the selected frame." To me, that says that the frame must be _selected_. It says that it makes no difference if the non-nil & non-t value is itself a frame: the SELECTED frame is used even if you pass a different frame as arg. The Emacs 24 doc string says something _very_ different - something that accords with your suggestion. It says that a value that is a _frame_ means: "consider all windows on that frame only." Here, "that frame" is presumably the frame passed as argument. However, I wonder if that is correct. The _code_ itself is unchanged from Emacs 20 through Emacs 24. Yet the doc string says something very different suddenly. I see nothing in the `one-window-p' code that deals with a frame value, or a `visible' value for that matter. Perhaps these special cases are handled by one of the functions it calls? Can you explain? Is the Emacs 24 behavior actually different from before, or is it just the doc that is different? Is the Emacs 24 doc string correct for 24? Is the 24 doc string perhaps correct also for older releases? (I see nothing in NEWS about a behavior change.) If your suggestion is appropriate, including for older releases, then I'll be glad to adopt it. Please let me know. Note: I have this comment in the code just before the call to `one-window-p'. I do not recall the issue, but the comment has been there for quite a while: ;; We should be able to use just (one-window-p), ;; but an Emacs bug means we need this: (one-window-p nil 'selected-frame))) Does that ring a bell? Even if that bug has since been fixed, I will presumably need to keep that, for older releases. Just wondering if you recall anything about that bug. > > The call to `save-selected-window' somehow gave the focus > > to the *Completions* frame. The solution was to change > > `save-selected-window' to `save-window-excursion' here. > > I don't know why, but I'm hoping you will. > > You mean that `save-select[ed]-window' can redirect focus and not > direct it back to where it was before calling it? That's certainly what it seems like. And there is definitely a difference here wrt what `save-window-excursion' does (that function DTRT here). Perhaps this info gives you a starting point for investigating. > If this is the case, please check whether it happens in Emacs 23 > as well and file a bug report (without referencing > `1on1-fit-minibuffer-frame', if possible). Yes, AFAICT the behavior is the same in all Emacs versions. Do you have a suggestion for a simpler test? If so, perhaps you can test it. > > 2. This was called near the beginning of the > > `1on1-fit-minibuffer-frame' body: > > > > (let* ((frame (save-selected-window > > (select-window (minibuffer-window)) > > (selected-frame))) > > Do you mean (window-frame (minibuffer-window)) here? I suppose so. _Should_ that make a difference? Certainly that is lighter weight than `save-window-excursion', and it seems to work OK so far. Thanks for the suggestion. Please let me know about the other occurrence (above) - I would like to change that also, if your suggestion will work there as well (for all Emacs versions). > > 3. At the end of the `1on1-fit-minibuffer-frame' body > > there is this call: > > (1on1-set-minibuffer-frame-top/bottom) > > > > The code for that function is this: > > > > (defun 1on1-set-minibuffer-frame-top/bottom () > > (when 1on1-minibuffer-frame > > (condition-case nil > > (if (fboundp 'redisplay) > > (redisplay t) > > (force-mode-line-update t)) > > (error nil)) ; Ignore errors from, e.g., killed buffers. > > (modify-frame-parameters > > 1on1-minibuffer-frame > > `((top ,@ (or 1on1-minibuffer-frame-top/bottom > > (- (* 2 (frame-char-height > > 1on1-minibuffer-frame))))))))) > > > > Here the problem was the call to `redisplay'. I changed > > (foundp 'redisplay) to just nil to fix things - > > `force-mode-line-update' works without changing the focus. > > > > `redisplay' is defined in C code. I do not know why it > > causes a problem here (why would redisplay change the input > > focus?), and I don't know what the proper solution might be, > > except to just use `force-mode-line-update' as I was already > > doing in older Emacs versions (which do not have `redisplay'). > > > > Do you have an idea about this? Does any of this make > > sense to you? > > No. Can't you distill a simple test case? `redisplay' shouldn't care > about frame focus either. You are saying the same thing I am. Can you distill a simpler test case? > > Each of these fixes is needed for > > `1on1-fit-minibuffer-frame'. Reverting any of > > them brings back the problem (giving *Completions* the > > focus). I do not understand any of these fixes (why they work), > > and I am certainly not claiming anything about them or about > > the problem, which I do not understand. I am only > > saying that together these changes fix the problem I encountered. > > > > But if you can explain things I will be glad to learn. > > I can't explain any of these. In the past, I tried to make > most window functions work on any window/frame to work independently > from the selected window. Earlier, selecting a window must have > been a very simple procedure. Nowadays, this incurs so many > side-effects in the window/frame/display area that you should > try to avoid `select-window' wherever possible. You seem to be saying that Emacs has introduced bugs, and nothing more. OK, so I hear the admonition to avoid `select-window' wherever possible. That's a sorry state, though. You seem to be saying that things that used to work, and work simply, are now so bugged or complicated that all we can advise is to avoid using `select-window'. Anyway, my updated code seems to take care of the problem I encountered. I would like to know about `one-window-p', however. Is the Emacs 24 doc string wrong? The code is identical to the code for Emacs 20.7, but suddenly we have a very different behavior description. Is the new description correct for Emacs 24 plus older releases? That would be good news (just an old-doc bug). For the moment, the situation is not clear.