From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Implementing child frames on terminal Date: Thu, 14 Jul 2022 08:56:33 +0300 Message-ID: <831quoutim.fsf@gnu.org> References: <87czfxu7be.fsf@disroot.org> <874k19tya1.fsf@disroot.org> <83h759lb6f.fsf@gnu.org> <87tu99s860.fsf@disroot.org> <838rqklurd.fsf@gnu.org> <87tu7n10hr.fsf@disroot.org> <83r12qxyxf.fsf@gnu.org> <87wnciv48c.fsf@yahoo.com> <83czeaxwwm.fsf@gnu.org> <87o7xuv3l1.fsf@yahoo.com> <83a69exvni.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30460"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, akib@disroot.org, emacs-devel@gnu.org, ibluefocus@outlook.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 14 07:58:33 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBrrt-0007mP-2L for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jul 2022 07:58:33 +0200 Original-Received: from localhost ([::1]:48094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBrrs-0006mE-0D for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jul 2022 01:58:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBrq7-0004md-DV for emacs-devel@gnu.org; Thu, 14 Jul 2022 01:56:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38050) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBrq5-0000IR-Lx; Thu, 14 Jul 2022 01:56:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0KWLofsqi/zVlAks7ST/DMEQgnR+40/uVs/hfzO0Zlk=; b=J52/QCqP2Kx3 CjHDHs2AgJ2Wl2q5c28RTNXXVgxcK0D0f2Z781gDbyQhgsOx9Xb8rPy3in02jPikJaml9y9zL3OdE Bjk8L2VWQAUqR+K0xb2Fx4hhkWtQbbSayP+6aezxGw0/Pzw0SaSECJtTjNHRXmKRl7msZv6tNh2dK FrKzsdTj0OA8Skij69iLQT/zm0w37BigmRnQOtZTfM42rVoujmdkfp0jXtLZsNgY0cd/EyCYXe5s7 iZF81Wqfyo0LG67A7XT3HR6JWwlRjYnEWXV0vQRYJ6dJspFJAMxQpbi2IMzqxbB1oA2mgTzgPK2a9 rZVYFCayTU1OUrsitrCyMg==; Original-Received: from [87.69.77.57] (port=1182 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBrq4-0005Nw-QY; Thu, 14 Jul 2022 01:56:41 -0400 In-Reply-To: (message from Stefan Monnier on Wed, 13 Jul 2022 21:55:16 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292128 Archived-At: > From: Stefan Monnier > Cc: Po Lu , 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.) > 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.