From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Question about minibuffer and child frames (Posframe) Date: Fri, 04 Oct 2024 11:16:50 +0200 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27122"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Emacs Devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 04 11:18:08 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 1sweRq-0006nF-4Z for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Oct 2024 11:18:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sweQk-0005eT-7l; Fri, 04 Oct 2024 05:16:58 -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 1sweQi-0005eB-Cz for emacs-devel@gnu.org; Fri, 04 Oct 2024 05:16:56 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sweQg-0003lZ-SD for emacs-devel@gnu.org; Fri, 04 Oct 2024 05:16:56 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-42cafda818aso18461175e9.2 for ; Fri, 04 Oct 2024 02:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728033413; x=1728638213; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=VQJNb8qte52BP31ernRZpLhOxd5upqb8ylAAFGquXnw=; b=I1prIGLbfTlwJ3UC3UkmO5svvPbnaEJpdmxYnaFZyJ/gkC2K5hCPBGzAfSz/p8odQv aROgY8ew39LJDQjrS55qsn8mDUCUxiGM4zg/GxgPmsMATd1uvx09nup9AkPQCLoSIqVp zPTBdZc6TFPhGmrzGtB23+Yf5j8fJU1rSydgJ7VEP8+RdpaW5mbmoWKuq4eavmsl7wUj Nrt7OX7N/Oalxb8QMKJaFNd+bgPDEQJGoWRQ+GUyUh7Lnasxz6ms54kiDdRnV4vPCRa4 1kCIMhc9UM5uNsI6dygUKbf+cqxsDNAOfJECT8VNWGT6m8v1JBFkHtWN+9Gil3hW6+p8 +/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728033413; x=1728638213; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VQJNb8qte52BP31ernRZpLhOxd5upqb8ylAAFGquXnw=; b=KiyLujHhxQonYoCudJggIn+4irLlE7ehEutofXMqEVDE1F+ZerRV0PGamdH4CMSuuF siGB8rh2RDt3/IwyShBdVAl/et17+wJqmfEJznFsg7mPs0Qv6UUAaw74PVXGYf0N9ojx m2qu3BAvtzN0ksV+pItSQBDCUbvPk5YiZU2qC7VLkTcDFMj/h/C7H7LENWlkyxBKD1Fk Rc+5AKLxHbprSS0+fbCk904luJzyRqc6vmFkcvKY+vH+C1Lt/gR2fsP+PcFzV+xlX7Mu qtO6+6/AV9Rn7AFVip/fiiv9ILYFlWDge5UYu/KLPe7qRfy2V1ExMtUVisFAJ7GZl8WY g8nQ== X-Gm-Message-State: AOJu0Yw2hqlJ9YTsu7vpFlTx/hiXYl899vK59YTCdd0f5rJ0y4F+Qx28 8nGJCcc2EPdQZfPEgb3gXoBHNu/mIqPytva4Hb4mHUyOZdLy6sMg7yIlFQ== X-Google-Smtp-Source: AGHT+IGmyyCb/ISHfRn/KA51WCp7MMKmsoaE7bSjxBKCHFwTNXp5vcD2yEfJ0WUwOXGn9e9nN9T8bA== X-Received: by 2002:a05:600c:35c3:b0:428:f0c2:ef4a with SMTP id 5b1f17b1804b1-42f85aa817emr14596265e9.13.1728033412443; Fri, 04 Oct 2024 02:16:52 -0700 (PDT) Original-Received: from MacBookPro.fritz.box (p4fe3a2d9.dip0.t-ipconnect.de. [79.227.162.217]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42f86a0afc1sm10767135e9.1.2024.10.04.02.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Oct 2024 02:16:52 -0700 (PDT) In-Reply-To: <0f426aa4-50a7-427a-b865-286f11fa6cbd@gmx.at> (martin rudalics's message of "Fri, 4 Oct 2024 10:10:33 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, 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:324306 Archived-At: martin rudalics writes: >> 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. 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? Oh, and then there are minibuffer-only frames, which I'd bet are not implemented for ttys. > - 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... 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. > 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. 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. And z-group or what the name was. > 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. 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. The only packages I have encountered personally using child frames are Posframe and Corfu. (If someone knows of other packages using child windows, I'd be interested, BTW.)