From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer' Date: Sun, 29 Oct 2017 16:56:49 -0700 (PDT) Message-ID: <2cb4dbe7-57a6-4a87-9897-224f2d602abe@default> References: <4d0c5535-246a-4356-914f-3c8d030ba9c9@default> <59F0412F.9090206@gmx.at> <22c73180-e9a6-416f-9e28-da98d07908f8@default> <59F1957F.80900@gmx.at> <59F2ED8C.3010400@gmx.at> <31caab4d-f332-48a7-9736-ccd172073672@default> <59F443A7.1020207@gmx.at> <4851dc90-59c3-49a9-b03c-add382e9b8bf@default> <59F5B8F1.1050909@gmx.at> <59F61A30.30300@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509321496 12135 195.159.176.226 (29 Oct 2017 23:58:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Oct 2017 23:58:16 +0000 (UTC) To: martin rudalics , 28978-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 30 00:58:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8xSu-0001y9-S0 for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Oct 2017 00:58:05 +0100 Original-Received: from localhost ([::1]:38112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8xT2-0000el-Co for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 19:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8xSw-0000ed-0R for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 19:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8xSs-00087Q-So for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 19:58:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60650) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e8xSs-00087D-Oy for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 19:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e8xSr-0004EV-Q4 for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 19:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Oct 2017 23:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28978 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28978-done@debbugs.gnu.org id=D28978.150932142116194 (code D ref 28978); Sun, 29 Oct 2017 23:58:01 +0000 Original-Received: (at 28978-done) by debbugs.gnu.org; 29 Oct 2017 23:57:01 +0000 Original-Received: from localhost ([127.0.0.1]:41098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8xRt-0004D4-B5 for submit@debbugs.gnu.org; Sun, 29 Oct 2017 19:57:01 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:28171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8xRs-0004Cm-EP for 28978-done@debbugs.gnu.org; Sun, 29 Oct 2017 19:57:00 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9TNurSR007234 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 29 Oct 2017 23:56:54 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9TNuqNi004390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 29 Oct 2017 23:56:53 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9TNuopx001936; Sun, 29 Oct 2017 23:56:52 GMT In-Reply-To: <59F61A30.30300@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:139171 Archived-At: > > And no, there is no problem such as (I think) you > > describe. In my own setup (but the code is not just > > for my setup) ALL of the frames except my standalone > > minibuffer frame have a nil `minibuffer' parameter. > > And none are mistakenly removed. Only the windows > > and frames showing BUFFER are affected, and only > > windows showing BUFFER are removed. >=20 > Then I have difficulties to understand what this part of your code tries > to do: > (setq mini-param > (cdr > (assoc > 'minibuffer > (frame-parameters this-frame)))) > (eq mini-param (active-minibuffer-window)) >=20 > You set mini-param to the 'minibuffer' parameter of this-frame which is > IIUC your *Completions* frame. Yes. > If you say that this parameter is always nil for this-frame, > why do you retrieve it? In my setup all frames except the minibuffer frame have no minibuffer. The code is not only for my setup. It is Icicles code, so it must handle any kind of setup. > If all you want to check is whether this-frame is the active > minibuffer window's frame, then there should be easier ways > to do that like, for example, > > (and (active-minibuffer-window) > (eq this-frame (window-frame (active-minibuffer-window)))) Yes, that looks like it corresponds to the check I've been doing - thanks. I was checking the `minibuffer' parameter of THIS-FRAME, to see if it was the `active-minibuffer-window'. But it should be just as good to check that the frame of the `active-minibuffer-window' is THIS-FRAME. I don't think the code you showed earlier corresponds to the same thing. IIUC, the test you suggested earlier checks whether the window that was selected immediately before the current minibuffer window was selected is the same as the selected window of THIS-FRAME. That's not the same thing as what I need to test, AFAICT. But your latest suggestion seems to check what I've been checking, and it should work OK in all Emacs versions. > > And even if that is the actual meaning/behavior of > > that function, the doc string is not appropriate. > > In that case it is inappropriate because it allows > > the other meaning: after instead of before. Either > > way, the doc string is misleading/ambiguous. >=20 > Please suggest a better one. Return the window that was selected immediately before the current minibuffer window was selected. One way or another, it should say that the window returned was selected BEFORE the minibuffer window was selected. It is not the minibuffer window (which can easily be understood as "the window selected when entering the minibuffer"). > > Could you please post the fixed string here, so I > > can see it? Clearly I don't understand this yet. > > Hopefully that will help. Thx. >=20 > The doc-string is probably not much better: >=20 > Return the window which was selected when entering the minibuffer. > Return nil if the selected window is not a minibuffer window. Right - not better. Same problem as before: "when entering" is ambiguous. Some window is the selected window before entering, and some window is the selected window after entering. But "when entering" means little - whether it is regard as an instant or a time period, either way it's unclear which window is meant - before or after the minibuffer window becomes the selected window. Plus there is the ambiguity of "the minibuffer" when talking about minibuffer windows, since there can be multiple minibuffer windows. And a minibuffer window could be selected before another minibuffer window gets selected. "When entering the minibuffer" tells you nothing about which of those minibuffer windows is the `minibuffer-selected-window'. > The Elisp documentation now has >=20 > This function returns the window that was selected > at the moment ^^^^^^^^^^^^^ > the minibuffer was entered. If the currently selected > window isnot a minibuffer window, it returns `nil'. >=20 > which you might want to improve as well. Same problem; same solution - see above. At the moment the change is made, which window is the selected window? My suggestion is to say that it is the window that was selected JUST BEFORE the minibuffer was entered. Thanks.