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

[Drew Adams]

>  > So the meaning of frame-parameter `minibuffer' has changed.
>  > I will need to adjust my code somehow.
> 
> Not really.  It should specify the minibuffer window used by that frame
> if the frame doesn't have its own minibuffer window.  Otherwise, it's t
> if this is a normal frame with its own minibuffer window and 'only if
> it's a minibuffer-only frame.  nil only serves as an initial value where
> it's up to Emacs to decide which minibuffer window to choose (something
> it eventually may have to do anyway).

Yes, that is what the doc says and has said.  The actual
meaning, i.e., what Emacs actually does, has changed.

But I don't wish to argue about whether the meaning
has changed - "meaning" can mean intended meaning or
behavior, and intended meaning can mean what was
coded or what was documented for it.

The actual behavior has changed.  I hope we can agree
on that wording.  And I will therefore need to adjust
my code.

>  > How would you suggest I change the test I have been using,
>  > to detect a frame that has the active minibuffer (versus
>  > the case I reported, where dedicated frame `*Completions*'
>  > has no minibuffer)?
> 
> 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.

I suppose you can close this bug now.  I can follow up
later if it seems there is still a problem.  Thanks.

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.

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

> It's a pity that you were not around when I tried to discuss the
> associated code here.  Maybe together we would have found a more
> convenient solution.

I'm sorry I wasn't.  As you know, I'm no expert in this
(or any other Emacs) area.  I can only see a change in
behavior and then ask about that.  I didn't see the
change before.

If it could help, next time you might ask me to try a
proposed Lisp change that you suspect might affect code
I have.  I would try it and let you know.  If there are
changes in C (as in this case) then I won't be able to
help, but if it is Lisp only then I will likely be glad
to check.

I just looked at the emacs-devel thread you cited, and
I see that I did follow it at the time, and flagged
some of the messages as noteworthy.  I didn't have
anything particular to say about it, as I didn't know
how it might affect my code.  So I "was there"
(reading), though I was "not there" (speaking up).

As you yourself said then, you would need to wait for
reports of problems (regressions etc.).  And here is
one. ;-)

I just need something that works.  At first sight your
suggestion looks like it will fill the bill.  Thanks.

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.