Re: Implementing child frames on terminal

[Akib Azmain Turja]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Po Lu <luangruo@yahoo.com>,  akib@disroot.org,  emacs-devel@gnu.org,
>>   ibluefocus@outlook.com
>> Date: Wed, 13 Jul 2022 21:55:16 -0400
>> 
>> >> Someone might want a popup implemented as a child frame to extend past
>> >> the bounds of the parent, for example.
>> > Why would they want that?
>> 
>> I can imagine a situation where a tty frame is split into two windows
>> and some company/corfu-style completion wants to popup a child-frame to
>> show completion candidates (basically like a menu), and if the
>> completion is near the split between the two windows, it would be
>> natural for that child-frame to extend into the other window if that can
>> make its contents more readable.  It would even feel odd if that
>> child-window were restricted to fit within its "parent" window.
>
> Such popups must be limited in their height anyway, so I see no
> problem in limiting them to their parent frame.
>
> (I also don't think child frames are the right basis for implementing
> such popups: they will look ugly.  Emacs frames are not suited for
> emulating GUI dialog widgets.)

What?  Completion popup is a misuse of child frame?  Then what its
supposed to do?

>
>> BTW We currently see "the same" with your menubar code in ttys, where the
>> menus aren't restricted to live within one of the existing windows
>> either, instead they're overlayed above the windows without regards for
>> the existing window splits.
>
> But they never cross the frame's border, which is what this discussion
> is about.  More importantly, I very much doubt that we'd want the
> child frames on TTYs to have the same limitations as TTY menus must
> abide by.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

signature.asc
Description: PGP signature