Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> 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.
>
> You'll just have to fix that for child frames.  I'd do it both ways:
>
> - Normal frames should be allowed to have their minibuffer on one of
>   their child frames.

I've seen that as a possible value of the minibuffer frame parameter in
the Elisp manual, but couldn't figure out how that would be used.
Probably I'm missing something. Is the child frame then automatically
shown/hidden? Why would someone want to do that, especially on a tty?

Oh, and then there are minibuffer-only frames, which I'd bet are not
implemented for ttys. 

> - Child frames should be allowed to have their minibuffer on another
>   child frame with the same parent or on any of their ancestors.

And prevent cycles and so on...

I'll have to see how involved that all gets. I'll probably start with
allowing a root frame's mini-window for a child frame, because that's my
immediate use case, and then see how that goes.

> You would, however, have to be careful when reparenting/deleting child
> frames
>
> - if the child frame uses its normal frame as the one hosting the
>   minibuffer window (reparenting only)
>
> - or if the normal frame uses the child frame as the one hosting the
>   minibuffer window.

Yeah, frame deletion in general is another open point on my todo list.
I've also seen frame parameters delete-before/after which I don't know
if I need them. And z-group or what the name was.

> It's up to you whether you want to do it.  But if users should be given
> the same look and feel on ttys as they have on GUIs, I see no other way.
> If you have any doubts, please ask.

Well, another approach might be to let users/developers complain when
they are trying to use or write something that requires these advanced
capabilites, and add that then. That prevents investing time in
something no one uses.

The only packages I have encountered personally using child frames are
Posframe and Corfu. (If someone knows of other packages using child
windows, I'd be interested, BTW.)