Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> I can only guess that that is part of how the `minibuffer' frame
>>> parameter is supposed to work, but I really have no ideda. The Elisp
>>> manual simply says
>>>
>>>       If the value is a minibuffer window (in some other frame), the
>>>       frame uses that minibuffer.
>>
>> If the posframe uses its own minibuffer window as value, then this would
>> probably work.  store_frame_param would set the parameter value to t in
>> that case as follows
>>
>>        else if (FRAME_HAS_MINIBUF_P (f))
>>          {
>>            if (EQ (val, FRAME_MINIBUF_WINDOW (f)))
>>              val = Qt;
>>
>> You would have to verify via
>>
>> (frame-parameter posframe 'minibuffer)
>
> Thanks, that was an interesting hint. I'll try that maybe tomorrow.
>
> I found something interesting too. I forgot to call window-list on the
> posframe in a way that it includes mini-windows. When I fix that
> I see that the GUI posframe has 1 window, but the tty posframe has 2,
> one of which is a mini-window.
>
> Whatever the effect of that is overall, it explains why the posframes
> and the Corfu frames are consistently 1 line too tall. Nice!

Well, make-terminal-frame has this:

  /* On terminal frames the `minibuffer' frame parameter is always
     virtually t.  Avoid that a different value in parms causes
     complaints, see Bug#24758.  */
  store_in_alist (&parms, Qminibuffer, Qt);

So, no experiments with the minibuffer frame parameter possible.

I think I have to implement the moral equivalent of x-create-frame's
minibuffer handling first, at least for child frames. I don't think
it makes sense for root frames. Will probably take me a bit, depending
what "virtually t" encompasses.