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 10:10:33 +0200 Message-ID: <0f426aa4-50a7-427a-b865-286f11fa6cbd@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> 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="2377"; 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 10:11:18 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 1swdPC-0000Ub-2X for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Oct 2024 10:11:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swdOZ-0005JN-Dz; Fri, 04 Oct 2024 04:10:39 -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 1swdOX-0005Ia-QE for emacs-devel@gnu.org; Fri, 04 Oct 2024 04:10:37 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swdOV-0001W7-M0 for emacs-devel@gnu.org; Fri, 04 Oct 2024 04:10:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1728029433; x=1728634233; i=rudalics@gmx.at; bh=VsD6bxlr4FefARSaQsM/lxUfc6yi9q7ix1bfoB13aHE=; 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=ngXoTisenpr70mwAVvkI6IUVJ7nrDq8JZOcQgNspAXNn2/ahsgDbLf4OFLFO8eKz L4+4MykaTWfp1fBrf1EJeDK9DjbM8npzKJnxDBx/0qJaoVh6PMIK9+jc16+DnaYMb nkx09//ayXdPX7TXM9waVhmKKdC4Z+LTvPvauXhF4LK5kYiyfyjqkYA+lIakneh6d /WH0TEU7G+yIqm+l03BvyTTi+D2tvZv9oiK5msrQXhit1qBcIkjmdZvLyhUMa4+Yv 8VkNpK+OZVINVlkl1rq5ia1JDxw+5njCY6EOoeXwHRvWP5iwDmVPAJgoDC1mDJ+U+ fY1sWL9xoNTmMWfpcQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([46.125.249.89]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MuDc7-1s2Cv633ef-00rWqq; Fri, 04 Oct 2024 10:10:33 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:IgGWm2lBx2+9YAJSWX74HlzprJb0u6WQuFjn8Ycnbev++JYarrf oNdgF3eqfl6ErhWPk3b+T8TfcR9g5F8cjsYioQOHg3bPD9mMn86xHl8XS/hA2hFpSO7mnPi nWKg5K6iourPlMu92mdvrmKCvh+tmR/fS8scJPUxacfdKUY395HHpAO1laU0l/2yX4IdouX CCUdTr1nJysPO+rdI5fMg== UI-OutboundReport: notjunk:1;M01:P0:hL5ci04dH9E=;v0r2m9mwFd2WkwhNEWrmUM14V7O XHXCT1syqOJ3O+pCQ5mNPi8fjWLkYfArHAvp1nmxlu6Uv0ZClbJVGJ3pZb1IaNRN5Lcou/AKe fodi3P4eWh7/yoo8fTjldGJtMdFlnePpNpZr4elMlMSG09xX4guAJRwhtNURV5F4rzoBE0MJH j4VfWsqQsyTv0zXFEW35JT9YodYkSq6xyDpZz5iKpJqNT1kS7KB21YAGb694rT5hr8A/WPgRS sgijppQc9mWW/dlkFZsE1ps7jc6C4KHe4x+ztlMW5BfUkhPAIqeKvHJ/vOJgA/T98ED23vSp2 0PYVgnNkgIgUslkTOLVWtUhzZ9EaVxQWt2KvVrAMT1POXx4OrSbq+YSFLELVyEXlVFJlLcLSB MjJDhL3HVPchtFTx/6Wy/+OUyTuPno09m/aSPVCeCAWJaoRgvAwNpPGGIOSpGkJkt0Cz3Lq80 XWrw1x3jZ9BPogSOlcQqqRbIC++x2sW45263r4KQCGUeGjh3KGZS34eHXg/sz+v06df+Sbr1z fOWRNcMWvf+wes8Fju0ioLyRQk4HN7EJS7mAwVrVKlqqh0qIEUpiyAeSuUzB2X+8Es/vLlYUY MZJifJDFVFj8kfkKcgIGsHNDqD0/floZZmFuwXNLf8Lov2VVV/OWZj0LARiu+4OvrLv+B5RiY Ayw6KvG8txFdLHAk1D6qF1jWC9kUPvU4tKjgUK7qXmdLpYRvrwKwxO0hc8vP+SnI1I5oToTOm JXp2SUlrlf0dxUnTWT3GBmgNozM2u2KIfhrJecHIzMTyKFZ8zEtXGLBNMcSpegvcLf0QgZs1 Received-SPF: pass client-ip=212.227.15.15; 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_H3=0.001, RCVD_IN_MSPIKE_WL=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:324304 Archived-At: >> I thought when the two windows are neighbors (which they often enough >> are) we could flip them. > > Flip windows would work to swap when they are sibling windows, and > neigbor windows can sometimes not be siblings. Right. I meant siblings (it was the typical two windows frame I had in mind). > I can't comment much cuz I'm not really familiar with these functions, > but one thing that pops out is would maintaining a dead windows table > take up lot of resources? No. It's already here via the variable 'window-dead-windows-table'. > Also do you think a function like 'window-rebuild-tree' would be useful, > and it accepts the a tree like the output of window-tree-pixel-sizes. > rn this is possible by using the following arguments for > window--transpose-1: > (window--transpose-1 tree-you-want (below . left) t) > However this is not really obvious. > > I think it could be useful to add a wrapper with more obvious name You would have to tell me in more detail what 'window-rebuild-tree' would do. One thing 'window-tree-pixel-sizes' should then possibly do is to include the identity of internal windows so 'window-rebuild-tree' could resurrect them as well. martin > 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. - Child frames should be allowed to have their minibuffer on another child frame with the same parent or on any of their ancestors. 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. 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. martin