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

[Drew Adams]

>  > 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.

Yes.

> If you say that this parameter is always nil for this-frame,
> why do you retrieve it?

In my setup all frames except the minibuffer frame have no
minibuffer.

The code is not only for my setup.  It is Icicles code, so
it must handle any kind of setup.

> 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))))

Yes, that looks like it corresponds to the check I've
been doing - thanks.

I was checking the `minibuffer' parameter of THIS-FRAME,
to see if it was the `active-minibuffer-window'.  But it
should be just as good to check that the frame of the
`active-minibuffer-window' is THIS-FRAME.

I don't think the code you showed earlier corresponds to
the same thing.  IIUC, the test you suggested earlier
checks whether the window that was selected immediately
before the current minibuffer window was selected is the
same as the selected window of THIS-FRAME.  That's not
the same thing as what I need to test, AFAICT.  But your
latest suggestion seems to check what I've been checking,
and it should work OK in all Emacs versions.

>  > 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.

 Return the window that was selected immediately
 before the current minibuffer window was selected.

One way or another, it should say that the window
returned was selected BEFORE the minibuffer window
was selected.  It is not the minibuffer window
(which can easily be understood as "the window
selected when entering the minibuffer").

>  > 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:
> 
>  Return the window which was selected when entering the minibuffer.
>  Return nil if the selected window is not a minibuffer window.

Right - not better.  Same problem as before: "when
entering" is ambiguous.

Some window is the selected window before entering, and
some window is the selected window after entering.  But
"when entering" means little - whether it is regard as
an instant or a time period, either way it's unclear
which window is meant - before or after the minibuffer
window becomes the selected window.

Plus there is the ambiguity of "the minibuffer" when
talking about minibuffer windows, since there can be
multiple minibuffer windows.  And a minibuffer window
could be selected before another minibuffer window
gets selected.  "When entering the minibuffer" tells
you nothing about which of those minibuffer windows
is the `minibuffer-selected-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 isnot a minibuffer window, it returns `nil'.
> 
> which you might want to improve as well.

Same problem; same solution - see above.  At the moment
the change is made, which window is the selected window?

My suggestion is to say that it is the window that
was selected JUST BEFORE the minibuffer was entered.

Thanks.