bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer'

[martin rudalics]

> Before your change, a separate *Completions* frame didn't
> have a minibuffer-window value for its frame parameter
> `minibuffer' - it used another frame's minibuffer.  Before
> your change checking that parameter was a reasonable way
> to check whether the frame had an active minibuffer window.

Your check does not do that.  It tries to check whether this-frame has
no minibuffer window and no minibuffer window is active.  Given the
Emacs 25 manual which says about the 'minibuffer' parameter

     Whether this frame has its own minibuffer.  The value `t' means
     yes, `nil' means no, `only' means this frame is just a minibuffer.
     If the value is a minibuffer window (in some other frame), the
     frame uses that minibuffer.

your check was not reasonable.  A reasonable equivalent check working
for Emacs 25 and Emacs 26 could be

(and (not (memq (frame-parameter this-frame 'minibuffer) '(t only)))
     (not (active-minibuffer-window)))

>   Return window selected just before minibuffer window was selected.

I used this.

> I don't think "currently active minibuffer window" is
> the same thing as currently selected minibuffer window.
>
> For one thing, a window is not "active".  (Nor is it
> "current", you will say, and that's right.)  You probably
> meant "window of the active minibuffer".

I tried to change the documentation in that sense.

> For another thing, if a minibuffer window is selected
> does that necessarily mean that the minibuffer is active?
> I don't think so, but I'm not an expert in this stuff.

You can always switch to a minibuffer window without making its buffer
active.

> Thanks for fixing this.

Thanks for the suggestions, martin