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#8856: 24.0.50; regression: special-display-frame is no longer dedicated Date: Sat, 25 Jun 2011 07:52:01 -0700 Message-ID: <4023AF2C90A24208ABCC1644CB15F776@us.oracle.com> References: <853BDEF1AA9646ACB90724066E1A5951@us.oracle.com><4DF65024.20305@gmx.at><0C191F638279437BADFCC697A5389F9E@us.oracle.com><4DF726A1.7020804@gmx.at><8E7452317D5B4FD183FD24E0FAA14F6F@us.oracle.com><4DFB6BBF.3080504@gmx.at><6FAF5DFD0E094823A512C3E0E87B6DF5@us.oracle.com><4DFE09A7.10500@gmx.at><0137606B527A48C69E3D6C704C5C6595@us.oracle.com><4DFF1709.3010409@gmx.at><309F7428711D4BEBB6063C60808D8069@us.oracle.com><4E00C54C.5080108@gmx.at> <7AF0B637CAE14034973FBCC658AFEBD9@us.oracle.com> <31769215C0FF4E1E89F9F641C5843E91@us.oracle.com> <4E033CBA.1050700@gmx.at> <4E037708.2000205@gmx.at> <4E045081.3020009@gmx.at> <90A40DD7F1B14BC1BE282ADB68D57511@us.oracle.com> <4E05ED7B.2070307@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1309013604 12453 80.91.229.12 (25 Jun 2011 14:53:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Jun 2011 14:53:24 +0000 (UTC) Cc: 8856@debbugs.gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 25 16:53:19 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QaUEZ-0000ec-6S for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jun 2011 16:53:19 +0200 Original-Received: from localhost ([::1]:50409 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QaUEY-00043g-5K for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jun 2011 10:53:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QaUEK-00043b-Dv for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2011 10:53:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QaUEJ-0005fD-1U for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2011 10:53:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QaUEI-0005f9-T9 for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2011 10:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QaUEI-00005M-DP; Sat, 25 Jun 2011 10:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Jun 2011 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8856 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8856-submit@debbugs.gnu.org id=B8856.130901354832756 (code B ref 8856); Sat, 25 Jun 2011 14:53:02 +0000 Original-Received: (at 8856) by debbugs.gnu.org; 25 Jun 2011 14:52:28 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QaUDk-0008WG-4A for submit@debbugs.gnu.org; Sat, 25 Jun 2011 10:52:28 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QaUDh-0008W2-Eh for 8856@debbugs.gnu.org; Sat, 25 Jun 2011 10:52:26 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.4/Switch-3.4.2) with ESMTP id p5PEqH4h028720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Jun 2011 14:52:19 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p5PEqGEH021406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jun 2011 14:52:17 GMT Original-Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p5PEqBJe013878; Sat, 25 Jun 2011 09:52:11 -0500 Original-Received: from dradamslap1 (/10.159.51.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Jun 2011 07:52:11 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E05ED7B.2070307@gmx.at> Thread-Index: AcwzQlfAMh1oVSFdRiGfhJdbZCfQvQAAJHzw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4E05F623.0044:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 25 Jun 2011 10:53:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:47457 Archived-At: > It's a pain to get ten files from there one by one. Can't > you pack them and send them in an attachment together with > the throw-... file? I suppose you have them in one and the > same directory and a thing like 7-zip around. So this > should be much easier for you ... There are several bulk download methods for Icicles, if you feel that right-clicking 10 times is onerous: http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Libraries#toc5 Try one of the 3 download scripts (see the first two bullets). If you don't like any of the bulk download methods then I will send a 7zip archive to you by mail - let me know. > > (let ((comp-buf (get-buffer-create "*Completions*"))) > > (unless (get-buffer-window comp-buf 'visible) > > (save-selected-window > > (display-buffer comp-buf t 0) ; <== the problem, no doubt > > (deactivate-mark)))) > > Could you explain what you think that happens, happens > instead, or does not happen here? "0" won't do anything > `display-buffer' without that argument would not have done > anyway: Search all visible and iconified frames for a window > showing comp-buf. (Again, to be sure we're on the same page, this is a call to `display-buffer' for Emacs prior to your changes. Perhaps I need to modify it now, for Emacs 24+.) The code above is Icicles code. Icicles does not require users to use non-nil `pop-up-frames' (and most do not probably). In my own, personal setup I use non-nil `pop-up-frames', but this code needs to work with any value of that option. You are the expert on `display-buffer', but this is my understanding. From the `display-buffer' doc string: Emacs 20: If FRAME is 0, search all visible and iconified frames. If FRAME is nil, search only the selected frame (actually the last nonminibuffer frame), unless `pop-up-frames' is non-nil, which means search visible and iconified frames. Emacs 22 says the same, but it adds "or `display-buffer-reuse-frames'" to `pop-up-frames'. Emacs 23 and Emacs 24 before your changes say the same as Emacs 22, but they distinguish the `graphic-only' case of non-nil for pop-up-frames. The Elisp manual says essentially the same thing. The Emacs 23.3 manual says only this about a nil value for FRAME (but it then lists a long page of other options that also affect the behavior of `display-buffer'). `nil' means consider windows on the selected frame. (Actually, the last non-minibuffer frame.) IIUC, in the above code, I do not want nil for FRAME, because I do not want only the selected frame checked for a *Completions* window. > Maybe there are reasons why this argument is needed and I > should put back its semantics but I never found one and > don't find one here. Do you see one now? Am I missing something? > IIUC the code tests whether it finds a visible window showing > comp-buf. If it doesn't, either because the window doesn't > exist or is not visible, it tries to get one on an iconified > frame or make a new frame New window, not new frame - no? Unless `pop-up-frames is non-nil etc. Again, please keep in mind that this is general code for users with all possible values of `pop-up-frames' etc. > and deactivate the mark there. So you probably raise the frame of > com-buf and then want to redirect focus from the comp-buf > window to your > minibuffer window which probably was selected here, and finally you > reselect the minibuffer window because of the `save-selected-window'. > But for some reason the comp-buf window remains selected. Is it that > what you see? I guess so. I don't know about the explanation of why, but yes, as I described earlier, for some reason the new *Completions* frame is getting the input (keyboard) focus. It is supposed to be a frame that always has its keyboard input redirected to the minibuffer frame. I suspect it's better to concentrate on the problem of input focus rather than speaking only in terms of window/frame selection. The new *Completions* frame _appears_ selected even prior to your changes (as shown by the window mgr border color, for instance), but the input focus is always correctly redirected to the minibuffer frame. That is the change (problem): the keyboard input focus. It seems (symptom, not explanation) as if the frame is no longer being correctly redirected, in terms of input focus. > Note: In all examples you sent me before you didn't have a thing like > `save-selected-window' around a `display-buffer' call. Not sure what you're saying there. Is that not a good idea? Thx - Drew