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 19:13:04 +0100 Message-ID: <59F61A30.30300@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> <59F5B8F1.1050909@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1509301012 5949 195.159.176.226 (29 Oct 2017 18:16:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Oct 2017 18:16:52 +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 19:16:48 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 1e8s8a-0000Ht-Nh for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 19:16:44 +0100 Original-Received: from localhost ([::1]:37309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8s8e-0007f7-HO for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 14:16:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8s61-0005e9-SD for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 14:14:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8s5y-0006On-Lo for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 14:14:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60407) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e8s5y-0006Og-Hi for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 14:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e8s5x-0002Xo-RL for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 14:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Oct 2017 18:14: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.15093008069719 (code D ref 28978); Sun, 29 Oct 2017 18:14:01 +0000 Original-Received: (at 28978-done) by debbugs.gnu.org; 29 Oct 2017 18:13:26 +0000 Original-Received: from localhost ([127.0.0.1]:40855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8s5N-0002Wh-Ul for submit@debbugs.gnu.org; Sun, 29 Oct 2017 14:13:26 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:65166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8s5L-0002WS-Rv for 28978-done@debbugs.gnu.org; Sun, 29 Oct 2017 14:13:24 -0400 Original-Received: from [192.168.1.101] ([46.125.250.68]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MYg42-1ddbhn29UQ-00VQV1; Sun, 29 Oct 2017 19:13:09 +0100 In-Reply-To: X-Provags-ID: V03:K0:rgv2Nu4RR9jy70BEUcV2LcO0YKno92yXAylDq4kth9URructPwV /I5v7wOUTE5srB8xVQc951FEZ8tV2ASNm4UhhIUcvuQxFUTXz6p89gYqciyjwfBalvonVWI a6AV169rlEt4qft3wYreVyJjkH3rkRU6qrXutQQ2Z2lauFfLA2LcpfPuTYj08753VxbKjx8 2BoEeBlXHbxno2Fiq5yzQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:obdZFKu36WE=:wfgAQEfAPLw7g0pMwl3M65 cVNISgqTs4UKTUYNl0omLtp5U6tsQxE9GxtMh4cNE1X/1Dd2DlIeXe72QVjKWt5Ff3PIwv6EJ l5xKxSi3MZNQrjludRc+nRp2O2mlVGJDiNKYSxw2dTZ4QjkwkQOlEKwDuOllRHAi9dmei6MOu iRVs2IJWZfU/+lBIaH/ZiZHHL1JUkj99qGJHuD0kT3iV8/ZceJ6pi0tny7N3TIJS16DQjgznE 1kV1uRWSsuddInM3/m7b9t9+7xJLtoY7N9XQlv8G+XBK4yAtDtlkM74DaOrBI31pR3JAjxgA8 VJ7gLNNnTskrPySjkFVWW4IXnc92k+FuBG6JiGh2TNDDML707zjwynVukbtMzVt57XPFhchFa ZzoTEjjDkdbFDRwPeRRpFaZq7wLvrC9u7+fG2cLkuEPZC12YZggy0w4uBkZH0NwMeBeKwu8P5 Icipb8AFGPKU1GirFRCW6aAJ012jQZat97Ly3yvgBht2fBKDVpU++seBZPNfVCXM345pO0WI9 E/L0N7YcUGTdOPyK74/FF0oz+GWAi9rOamh5EPvoYox+2JJ2idA743cfSpjibDA4YnW5dZlOz LbH8Byo1gbuSGwI4On0FN4Qit0gfkRypNwHrhy+SaRazNObwLEyO+nC2U409GSLgYUK1kW+1E jKF0d2QbNIOrlQ6CA74BvBX8NFg88HlEzUqdWBtZ7CCZ8J68FAE5Qs+AMw/igjyeo9z8mKNXn rxjOb98EWh0pvxEg8jJRfar9/zQN/trVed+FEkBYN1eC/2NxOZjpH/ysewsMf+Gtob8fo5AI 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:139160 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. 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)) You set mini-param to the 'minibuffer' parameter of this-frame which is IIUC your *Completions* frame. If you say that this parameter is always nil for this-frame, why do you retrieve it? 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)))) > Really? The window that was selected before minibuffer > interaction? Yes. > I truly do not understand, in that case. And that is > not what I think I see. If what you say is true then > I should never see that the same minibuffer window > as `active-minibuffer-window' (or even an inactive > minibuffer window) is itself returned by the function. Invoke emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))" and switch to the minibuffer-less frame. Type C-h f to enter the minibuffer. Once there, type M-: (active-minibuffer-window) This gets me the window of the minibuffer frame. Now type M-: (minibuffer-selected-window) This gets me the window of the minibuffer-less frame. What do you get? > How can the minibuffer window that becomes selected > for the minibuffer interaction have been the selected > window before "the minibuffer interaction started"? I don't know. It doesn't happen with the scenario sketched above. > 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. Please suggest a better one. > Let me ask you the same question you asked me about > my function for removing displays of a buffer: what > are the use cases for `minibuffer-selected-window'? > What is it intended for? I thought I understood it > until your reply saying that it returns the window > selected _before_ the minibuffer interaction. IIUC it's mainly used to find the original buffer from where the minibuffer was entered. Have a look at the Elisp sources. > 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. The doc-string is probably not much better: doc: /* Return the window which was selected when entering the minibuffer. Return nil if the selected window is not a minibuffer window. */) The Elisp documentation now has This function returns the window that was selected at the moment the minibuffer was entered. If the currently selected window is not a minibuffer window, it returns `nil'. which you might want to improve as well. martin