From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Question about minibuffer and child frames (Posframe) Date: Fri, 4 Oct 2024 11:31:41 +0200 Message-ID: <48876bb0-089e-4255-a09b-dc95dcd7ab0c@gmx.at> References: <1d2d916e-82b9-4672-bbd6-4583b5edad14@gmx.at> <24c75fcd-cbd6-4f7f-94d2-636814fcf4c7@gmx.at> <618c87b7-c5a6-40ee-8440-75f5b48bfc43@gmx.at> <2b259b34-35d7-49d7-96a6-a50eeee07896@gmx.at> <0f426aa4-50a7-427a-b865-286f11fa6cbd@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8078"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Emacs Devel To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 04 11:32:32 2024 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 1swefo-0001z3-CR for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Oct 2024 11:32:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swef8-0007bg-RB; Fri, 04 Oct 2024 05:31:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swef6-0007bO-4Z for emacs-devel@gnu.org; Fri, 04 Oct 2024 05:31:48 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swef2-0006Vk-OG for emacs-devel@gnu.org; Fri, 04 Oct 2024 05:31:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1728034302; x=1728639102; i=rudalics@gmx.at; bh=h3n0MTDGYIFqcinkDNhh+rM7/VQqX6NuMaf77kPbvus=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=XHfeqtPv4W3nKydMNTLWCfZVO7t4MlpAsQIeLycp4jXihlsh+ubsVzy8hyUdNsXR bYLFoZvbndz9lIVRErXVPwtsKZbdGZ+a37pUWTQ7RRY5MtmZAB0HIpJdL/w8uyO3N Ar0/jmWDq5AE53QlpBn34O8ayksJg5qfvm5BsM6QDsBjnyiP5QnHpw9+wu60BaKTJ 4xICl0KJMKTyQTUITZG2NQaBD4rz8da3WzsCO0ow14TSm6I8+YthQU/HZJnvebWtM OAU+PsjBEKpBOv5Ggn3AWvRQdg9bRGwFjTw9C/AGKuvY/FjgJABSaxawawHAvRr0J TUeU6QC2Zr89o1oQYg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([46.125.249.89]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQ5rU-1sahvK094q-00IgXj; Fri, 04 Oct 2024 11:31:42 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:TktwajOPloa86NRfXu/vPxOSjWZ0kj/GS5Kmize721Wldwhq+2v nTmCH1VO+leI7Uvr2owOfpXYvvJrMzxoGUeLTad58lREYS5fEuWCnJwonxeLYJMnQix7qXa 2S9t0IpNOyOekCr4Nfm69W34s0wxJFbrin2wTVNp4/Xnk1SUY6oEo3RM+zoSv4J5lKZRXV5 I41NuulJGATdnF+JxPOSw== UI-OutboundReport: notjunk:1;M01:P0:4KEN0ob1Eqo=;KwwMrcUXjqc+02oIgiX6Y+s6S8G JlevY1jEllDv2IPPvi0kpKp8TOerqW5Q41OyDCVJgeMKqPfS+UjZvqlu65Sek17SLGzs1FCyP kovPU1gWLFHt150dkT2vgI+tq6ZhQ8wAZp8g4MyTDC4d4PHggqxNPPEdZzrRKnYIVHYlZPZfm og7XirZakGH1DIvRZa1tm8VylgXB6TnQoy3U5HwZ8JWlcoU2RZRvSHP/kSjpdJSV6favyWopb Vn/GTGcKC76dl5ppfAaOY5Ki4/u8tSTbsACYbSYEsdEvy/sa10K0UwlghlTEXWCsQZwnLZoxa HpMvIVX6zN48Cqw4dCTBdTNO+7y7DimH3vGJdBXVrt7My+BaJaLxMbgTWHk1TNxCYPcKkFTZ2 llSxNJCN/dm1SrFaflfwhlYoeHbvUNAbs+rDvEIM3Vy2G7FeMD0r6giVw9H9AdoPxQoaVIU3K RBPHJlDCahuI/RcImd5JgWCw/Wp6Yub2+17z09iPVL5yge8fSPlXRoTxjKp/bPl8BqQOjOsUL hqTQHI2pXcVNufp2CxNCJp+R39K0D36M5c5oG3Omg96sHHOv22K6+J7P8OTSv04ds4z2ssqrE 1pVRRj0n+x2wSVfM3N4me1yk5MJJrS6gxhc8hjoIz2paiGy8l9vm1aPWfe9vNDj+9e+gv32hm E8YEKeds74Hh9daMHttgSZwvLpeDyLkSuu/5QCGTddAiKLZf0G+oNC1KRXkfSWKI3uJalnhRm lWeZ77Te0VMqNOCtFipXclrLz6kH45o0cQpljH/eylESr+usP16NVpnYHqpFZQWcbMUNWAOm Received-SPF: pass client-ip=212.227.17.22; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324307 Archived-At: > 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. >> - 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. > 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. > 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. > 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. martin