Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> 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?
>
> Users have often asked how to show the minibuffer only when it is really
> used in order to save screen estate.  Minibuffer-only top-level frames
> are one way to do that but they don't work on ttys.  Child frames could
> be used, if implemented accordingly.
>
>> Oh, and then there are minibuffer-only frames, which I'd bet are not
>> implemented for ttys.
>
> Right.
>

Hm, I think I'll omit that for now.

>>> - 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...
>
> The child frame code hopefully does that already.

Good news!

>> 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.
>
> Agreed.  But you would have to document it.
>
>> 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.
>
> They are obeyed by 'delete-frame' already.  You don't have to bother.

Also good news!

>> And z-group or what the name was.
>
> You need the z-order when you have two overlapping child frames.  One of
> the things the window manager handles on GUIs.

Yes, I needed a z-order pretty much from the start, to be able to
construct the combined root frame + children matrix that is written to
the terminal. Struct frame has a z_order member here which raise-frame
and so on manipulate (by calling a hook), and which redisplay can use to
compute child frames in z-order. No grouping though.

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

Thanks! I'll holler when I have something working, or think I have.