From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer' Date: Sun, 29 Oct 2017 12:18:09 +0100 Message-ID: <59F5B8F1.1050909@gmx.at> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509275954 1394 195.159.176.226 (29 Oct 2017 11:19:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Oct 2017 11:19:14 +0000 (UTC) To: Drew Adams , 28978-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 29 12:19:08 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 1e8lcQ-000845-JX for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 12:19:06 +0100 Original-Received: from localhost ([::1]:35624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8lcX-0004v2-QB for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 07:19:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8lcR-0004sQ-Vt for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 07:19:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8lcM-0004HJ-TM for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 07:19:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59347) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e8lcM-0004HA-P9 for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 07:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e8lcM-0005eM-Fo for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 07:19:02 -0400 Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Oct 2017 11:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 28978 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 28978@debbugs.gnu.org, rudalics@gmx.at, drew.adams@oracle.com Original-Received: via spool by 28978-done@debbugs.gnu.org id=D28978.150927590621667 (code D ref 28978); Sun, 29 Oct 2017 11:19:02 +0000 Original-Received: (at 28978-done) by debbugs.gnu.org; 29 Oct 2017 11:18:26 +0000 Original-Received: from localhost ([127.0.0.1]:39795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8lbm-0005dP-2v for submit@debbugs.gnu.org; Sun, 29 Oct 2017 07:18:26 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:53846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8lbj-0005dC-ON for 28978-done@debbugs.gnu.org; Sun, 29 Oct 2017 07:18:24 -0400 Original-Received: from [192.168.1.101] ([46.125.250.68]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MYfX0-1deXOZ3JDO-00VNPA; Sun, 29 Oct 2017 12:18:13 +0100 In-Reply-To: <4851dc90-59c3-49a9-b03c-add382e9b8bf@default> X-Provags-ID: V03:K0:R0erQjn8meJ/G/wCA7YrPUTCY/XM8nHKr0ZY4jatosMlsXd1oZP 3bA3UsDBZkvTqI7oQ/cizi10+tc/4JrSKqcCGDjVJX9jkdDGfvbS6wqhDwN3EsDyL1W4yen ufpPdGgYDrkUHq0FI5hUqxtkdwXMd+5194Y02mLE3f7puz9WhuiRwmzOqNBXfLxlMCGXzeP m0FuDqTnuWfdkTHnWVq+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:+1Y9rmCC4Pc=:PfPu24r1o55nSmzMifGvkh JIKLL4h9SjDkO50tZ0/23aSFVBA8kHvHCCqhCTqtJCAruYUqx+Ga1HGAD1gpDP/nI8nRdWBxs zWdlzDSEo3Fye3ud8FeqGLa+QtdbdoqHaWAWkTjX3RQfjexRTnRN94Ije12jWW9m26lzJ4z9V h2HhTEcVr2JzlE1xyegIRx0JpJUsM2Hf9bpJ1nvh3WUCYIXaZSKaGVdxxpc1NNJUG8sJldF2V i4BgB4V6d3TvodMwf4QhNnha8MnN/OxxTfV0KWWzSF96FjHe43G0LZQ54PK/md1KgoKPtglD+ rWVSob/7aFWIPTwov9FKGun7FReK+PKKQJW0wkqUa75uUTL9Zzm1o+y7mB0+WS+eHDdDdYQB0 8/3fprsW90dZn1ioQTyYByDgbF2NNl5MAaaT5Ave6UPL0OZDHeJaCHOaM1EuXgiDA3atu5WXi UhbkdlmPxw7rwfg3v/YMBYY4xDgeN3TKXZx/3+lfkSYDgL1/t5Ez6GC1Lg01ouDRc7dRHobzF TIdFu8Om031hjIBG7hcCS9saPwF5SfDxIxD2WGmdUcy8FaV3JCRra3XUi1cY3Gh/a+ZcXEjV6 EFHrK4zfdz/tlZGNc8SJbkCEKGGKeKKZEDqoOT0a3xkpu6l/EYv2ER4KIb55F7w9KfIffSa1F EhsXZOK3GJpGSbIEdnhiBpJSkgt93xw35O0VqJ9r28ZF79EmPc2Wy2d2R/Qg+vBhzbX0XGdQi /7yy7oFeh0e0HF9pXbadtgXFMg0TuAHbBhWrx/N42ObR/G9mZeI3gCMoC9oNqXxgQnIHmDud 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:139141 Archived-At: > The actual behavior has changed. I hope we can agree > on that wording. We can. >> 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. You never said what you really wanted to achieve. I guess that you want to delete a frame around the time you do some minibuffer interaction and base the decision of which frame to delete on whether it is the frame initiating that interaction. If so, then any code based on the value of the 'minibuffer' parameter would have been already wrong before my change as well - an arbitrary number of frames could have had the 'minibuffer' parameter set to nil and there would have been no way to tell from that parameter which of them initiated the interaction. > 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. Exactly that's the meaning. I'm afraid you're confusing things here. The window returned by that function was the selected window until the minibuffer interaction started. When the minibuffer action terminates, that function will return nil again. The active minibuffer window is obviously returned by =E2=80=98active-minibuffer-window=E2=80=99. > 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...".) Fixed, hopefully. I also rewrote the related documentation (to some extent). > 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. Done. martin