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: Sat, 28 Oct 2017 12:15:39 -0700 (PDT) Message-ID: <4851dc90-59c3-49a9-b03c-add382e9b8bf@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> 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 1509218244 27587 195.159.176.226 (28 Oct 2017 19:17:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Oct 2017 19:17:24 +0000 (UTC) To: martin rudalics , 28978@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 28 21:17:17 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 1e8WbP-0004rM-MI for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Oct 2017 21:17:03 +0200 Original-Received: from localhost ([::1]:33752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8WbX-0004Qx-1X for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Oct 2017 15:17:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8WbR-0004Qq-2s for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2017 15:17:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8WbN-0005gE-TX for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2017 15:17:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59038) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e8WbN-0005fx-Pf for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2017 15:17:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e8WbN-0004SI-Hw for bug-gnu-emacs@gnu.org; Sat, 28 Oct 2017 15:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Oct 2017 19:17: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-submit@debbugs.gnu.org id=B28978.150921817617064 (code B ref 28978); Sat, 28 Oct 2017 19:17:01 +0000 Original-Received: (at 28978) by debbugs.gnu.org; 28 Oct 2017 19:16:16 +0000 Original-Received: from localhost ([127.0.0.1]:39486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8Wae-0004R8-A1 for submit@debbugs.gnu.org; Sat, 28 Oct 2017 15:16:16 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8Wac-0004Qw-HC for 28978@debbugs.gnu.org; Sat, 28 Oct 2017 15:16:15 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9SJG7d3026395 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Oct 2017 19:16:08 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v9SJG6tm001114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Oct 2017 19:16:06 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9SJG5KX031256; Sat, 28 Oct 2017 19:16:05 GMT In-Reply-To: <59F443A7.1020207@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: aserv0021.oracle.com [141.146.126.233] 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:139125 Archived-At: > > So the meaning of frame-parameter `minibuffer' has changed. > > I will need to adjust my code somehow. >=20 > Not really. It should specify the minibuffer window used by that frame > if the frame doesn't have its own minibuffer window. Otherwise, it's t > if this is a normal frame with its own minibuffer window and 'only if > it's a minibuffer-only frame. nil only serves as an initial value where > it's up to Emacs to decide which minibuffer window to choose (something > it eventually may have to do anyway). Yes, that is what the doc says and has said. The actual meaning, i.e., what Emacs actually does, has changed. But I don't wish to argue about whether the meaning has changed - "meaning" can mean intended meaning or behavior, and intended meaning can mean what was coded or what was documented for it. The actual behavior has changed. I hope we can agree on that wording. And I will therefore need to adjust my code. > > How would you suggest I change the test I have been using, > > to detect a frame that has the active minibuffer (versus > > the case I reported, where dedicated frame `*Completions*' > > has no minibuffer)? >=20 > I would try (eq (minibuffer-selected-window) > (frame-selected-window this-frame)) I will try that. At first sight it solves the problem. As there are many different use cases I'll need to see whether it works in all cases and doesn't break anything. I suppose you can close this bug now. I can follow up later if it seems there is still a problem. Thanks. BTW, I find the doc string for `minibuffer-selected-window' a bit confusing: Return the window which was selected when entering the minibuffer. ^^^^^^^^^^^^^^^^^^^^^^^^^^ Returns nil, if selected window is not a minibuffer window. The phrase "window which was selected when entering" is somewhat ambiguous. It can easily be understood as the window that was selected before the minibuffer was entered, rather than the (minibuffer) window that is selected after the minibuffer was entered. I think it would be clearer to identify the "when" clearly as after entering, not before - when "entering' is unclear, especially when used with "was" selected. (Also, it should probably say "Return nil..." instead of "Returns nil...".) > It's a pity that you were not around when I tried to discuss the > associated code here. Maybe together we would have found a more > convenient solution. I'm sorry I wasn't. As you know, I'm no expert in this (or any other Emacs) area. I can only see a change in behavior and then ask about that. I didn't see the change before. If it could help, next time you might ask me to try a proposed Lisp change that you suspect might affect code I have. I would try it and let you know. If there are changes in C (as in this case) then I won't be able to help, but if it is Lisp only then I will likely be glad to check. I just looked at the emacs-devel thread you cited, and I see that I did follow it at the time, and flagged some of the messages as noteworthy. I didn't have anything particular to say about it, as I didn't know how it might affect my code. So I "was there" (reading), though I was "not there" (speaking up). As you yourself said then, you would need to wait for reports of problems (regressions etc.). And here is one. ;-) I just need something that works. At first sight your suggestion looks like it will fill the bill. Thanks. BTW, I don't see anything yet in NEWS about this change. I consider this an incompatible change (you might not). In any case, it should be called out, I think. I see a section called "New frame parameters and changed semantics for older ones". That might be a good place to mention this.