[debbugs-tracker] bug#28978: closed (26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer')

[GNU bug Tracking System]

Your message dated Sun, 29 Oct 2017 12:18:09 +0100
with message-id <address@hidden>
and subject line Re: bug#28978: 26.0; Regression: separate, dedicated 
`*Completions*' frame no longer has parameter `minibuffer'
has caused the debbugs.gnu.org bug report #28978,
regarding 26.0; Regression: separate, dedicated `*Completions*' frame no longer 
has parameter `minibuffer'
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
28978: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28978
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer'
>
>
>
>
> Date: 
>
> Tue, 24 Oct 2017 13:20:17 -0700 (PDT)
>
>
>
>
> In my code I check (essentially) this:
>
> (let ((swin  (selected-window)))
>   (when (window-minibuffer-p swin) (setq swin  (minibuffer-selected-window)))
>   (and (get-buffer-window "*Completions*")
>        (window-live-p swin)
>        (not (eq (window-buffer swin) (get-buffer "*Completions*")))
>        (interactive-p)))
>
> It does what I expect in all Emacs releases, but not in this
> prerelease.  My `*Completions*' window is in its own one-window frame,
> with the window dedicated.  Input for that frame is redirected to my
> standalone minibuffer frame.
>
> It should be the case in my context that this returns the minibuffer
> window:
>
> (cdr (assoc 'minibuffer (frame-parameters
>                           (#<frame *Completions* 000000000cacf6c8>))))
>
> Instead, it now returns nil.  Parameter `minibuffer' for the
> `*Completions*' frame is no longer the minibuffer window; it is nil.
>
> This is the code that redirects the frame focus, which I guess is
> relevant:
>
> (let ((redirect  (if (active-minibuffer-window)
>                      1on1-minibuffer-frame
>                    (and completion-reference-buffer
>                         (get-buffer-window completion-reference-buffer 'visible)
>                         (not (eq (get-buffer "*Completions*") 
> completion-reference-buffer))
>                         (window-frame (get-buffer-window 
> completion-reference-buffer t))))))
>   (when redirect (redirect-frame-focus (selected-frame) redirect)))
>
> That code is in a function, `1on1-display-*Completions*-frame',
> that I use with `special-display-buffer-names':
>
> (add-to-list 'special-display-buffer-names
>              `("*Completions*" 1on1-display-*Completions*-frame
>                ((background-color ,@1on1-completions-frame-background)
>                 (mouse-color      ,@1on1-completions-frame-mouse+cursor-color)
>                 (cursor-color     ,@1on1-completions-frame-mouse+cursor-color)
>                 (menu-bar-lines . 0) (tool-bar-lines . 0) ; No menu bar or tool 
> bar.
>                 ,@(and 1on1-completions-frame-width
>                        `((width   ,@1on1-completions-frame-width))))))
>
> In GNU Emacs 26.0.90 (build 3, x86_64-w64-mingw32)
>  of 2017-10-13
> Repository revision: 906224eba147bdfc0514090064e8e8f53160f1d4
> Windowing system distributor `Microsoft Corp.', version 6.1.7601
> Configured using:
>  `configure --without-dbus --host=x86_64-w64-mingw32
>  --without-compress-install 'CFLAGS=-O2 -static -g3''
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer'
>
>
>
>
> Date: 
>
> Sun, 29 Oct 2017 12:18:09 +0100
>
>
>
>
> > 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 ‘active-minibuffer-window’.
>
> > 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
>
>
>
> --- End Message ---