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 08:59:56 -0700 (PDT) Message-ID: 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 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509293017 6688 195.159.176.226 (29 Oct 2017 16:03:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 29 Oct 2017 16:03:37 +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 Sun Oct 29 17:03:32 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 1e8q3d-0000or-KV for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 17:03:29 +0100 Original-Received: from localhost ([::1]:36950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8q3k-00036w-T6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Oct 2017 12:03:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e8q1L-0001PZ-0w for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 12:01:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e8q1G-0003q6-4O for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 12:01:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60339) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e8q1F-0003pv-Vu for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 12:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e8q1F-0005wo-Nf for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2017 12:01: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: Sun, 29 Oct 2017 16:01: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.150929283822818 (code D ref 28978); Sun, 29 Oct 2017 16:01:01 +0000 Original-Received: (at 28978-done) by debbugs.gnu.org; 29 Oct 2017 16:00:38 +0000 Original-Received: from localhost ([127.0.0.1]:40787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8q0r-0005vx-Fc for submit@debbugs.gnu.org; Sun, 29 Oct 2017 12:00:37 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:18279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e8q0o-0005vj-Si for 28978-done@debbugs.gnu.org; Sun, 29 Oct 2017 12:00:35 -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 v9TG0OEO021853 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 29 Oct 2017 16:00:25 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9TG0ONT021128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 29 Oct 2017 16:00:24 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9TG0NPB019337; Sun, 29 Oct 2017 16:00:23 GMT In-Reply-To: <59F5B8F1.1050909@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:139152 Archived-At: > >> 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. >=20 > 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. I sent the `icicle-delete-windows-on', which includes the doc string: "Delete all windows showing BUFFER. If such a window is alone in its frame, then delete the frame - unless it is the only frame or a standalone minibuffer frame." It's about deleting _windows_. It's only about deleting frames if the windows to be deleted are alone in their frames - such frames are the only frames that are deleted. That's what I want to achieve. Is it not clear? As for when that function is called from Lisp in my code (to see its use other than interactive), currently it is called only in command `icicle-remove-Completions-window'. But that function is called many times, throughout my code. A _typical_ use is to remove the display of buffer `*Completions*' at the end of a given minibuffer interaction. A user can also invoke it during completion using `C-x 0' - that's the interactive case. "End of a given minibuffer interaction" might be at or near the end of a command. It might be at or near the end of the use of a minibuffer. But it might NOT be, in the case of a recursive minibuffer, or even in the case of a non-recursive minibuffer with which interaction is not finished. E.g., you show completions for `forw', then you type `x', so your input is `forwx'. Display of `*Completions*' is removed because there are none. `icicle-remove-Completions-window' is invoked to stop showing `*Completions*' - wherever it might be shown; nothing more. And that can be appropriate in lots of different contexts. The code: (defun icicle-remove-Completions-window (&optional force) "Remove the `*Completions*' window. If not called interactively and `*Completions*' is the selected window, then do not remove it unless optional arg FORCE is non-nil." (interactive) ;; Do nothing if `*Completions*' is the selected window or the ;; minibuffer window is selected and `*Completions*' window was ;; selected just before. (let ((swin (selected-window))) (when (window-minibuffer-p swin) (setq swin (minibuffer-selected-window))) (cond (;; `*Completions*' is shown in the selected frame. (and (get-buffer-window "*Completions*") (or force;; `C-g' gets rid of it even if selected (and (window-live-p swin) (not (eq (window-buffer swin) (get-buffer "*Completions*")))) (interactive-p))) (condition-case nil;; Ignore "Attempt to delete the..." (delete-window (get-buffer-window "*Completions*")) (error nil)) (bury-buffer (get-buffer "*Completions*"))) (;; `*Completions*' is shown in a different frame. (and (get-buffer-window "*Completions*" 'visible) (or force;; `C-g' gets rid of it even if selected (and (window-live-p swin) (not (eq (window-buffer swin) (get-buffer "*Completions*")))) (interactive-p))) (when (window-dedicated-p (get-buffer-window "*Completions*" 'visible)) (condition-case nil (icicle-delete-windows-on "*Completions*") (error nil))) (bury-buffer (get-buffer "*Completions*")))))) > 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. No. As I said, the code, as it was, works fine in all Emacs releases. It does not work in prerelease 26.1. If multiple frames show the BUFFER (typically `*Completions*') whose display is to be removed then the behavior (intended and realized) is to remove all such displays of BUFFER - i.e., all windows showing BUFFER. 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. > > 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. >=20 > 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. Really? The window that was selected before minibuffer interaction? 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=20 as `active-minibuffer-window' (or even an inactive minibuffer window) is itself returned by the function. How can the minibuffer window that becomes selected for the minibuffer interaction have been the selected=20 window before "the minibuffer interaction started"? I suppose a _different_ minibuffer window could be returned, e.g., in the case of a recursive minibuffer. But so far, what you just said, about the function returning the window that is selected before the minibuffer interaction starts, makes no sense to me. I don't get that. That description seems to apply to a window showing `completion-reference-buffer'. That is not what I think I see. Before `M-x', with buffer `foo.el' current in the selected window, I don't think I ever see that window as the value of function `minibuffer-selected-window'. 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. 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. > When the minibuffer action terminates, > that function will return nil again. The active minibuffer=20 > window is obviously returned by =E2=80=98active-minibuffer-window=E2=80= =99. Yes, `active-minibuffer-window' I understand, and have been using. It is `minibuffer-selected-window' that was, and apparently still is, unclear to me. > > 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...".) >=20 > Fixed, hopefully. I also rewrote the related documentation > (to some extent). 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.