From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder Newsgroups: gmane.emacs.devel Subject: Re: "Final" version of tty child frames Date: Tue, 17 Dec 2024 21:35:35 -0800 Message-ID: <09b0904da92efad899865b2ece5f3116@finder.org> References: <86wmi0g0x6.fsf@gnu.org> <11a86987cce9fe0a257c3fa58703dc33@finder.org> <86wmgl6jzv.fsf@gnu.org> <092cb755eee3a9b5e06d15c0b07e90b1@finder.org> <276414b03c24964aaeb9e43e8dba5e77@finder.org> <5fedec86bce470555814acbdf999f99d@finder.org> <86h6791khk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36168"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, rudalics@gmx.at To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 18 06:36:40 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 1tNmjf-0009FO-AC for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Dec 2024 06:36:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNmiq-0008HI-Hl; Wed, 18 Dec 2024 00:35:48 -0500 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 1tNmio-0008Gm-Ue for emacs-devel@gnu.org; Wed, 18 Dec 2024 00:35:47 -0500 Original-Received: from greenhill.hpalace.com ([192.155.80.58]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNmim-0001vx-Um; Wed, 18 Dec 2024 00:35:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=finder.org; s=2018; t=1734500136; bh=gbhwFe6gSwEqgHMXsEz/4Sx/DqjRmA28nE7/Cy3o7t0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=A5xkiCgEUnACpjBFrGLj30j5HQVxnPB56XB9dsBp8TzC1uzlDVX9g7IZcxjmYHLz1 AjxvREj3YkzQEKEE08Ac0nPiKJ0dPsBWDWWLJ2xMAB3gbc/Tc7BDDYqA1vJ58SJGsd Gzb6CgexvMzlaHiC2e77itnrvCyBZQ95u2Lz5RSWRR3k5OSXxoEg4Mgq4ydc2qpS6C lRuurGs1TyKRK1Lxz8GbnXR4MirsdlThlDhJAl0ET5mLMlQt+VHsQVk63zQWGljMeu d4R22Be8jrUJjqwIu5BcMi8tgmYyzCSdhC4/2IBymvTDG8IzFr2QHwkODMUEmyrL5X Wc7LwFRWXeBIQ== Original-Received: from mail.finder.org (unknown [192.155.80.58]) by greenhill.hpalace.com (Postfix) with ESMTPSA id EC0AF16B6; Wed, 18 Dec 2024 05:35:35 +0000 (UTC) In-Reply-To: X-Sender: jared@finder.org Received-SPF: pass client-ip=192.155.80.58; envelope-from=jared@finder.org; helo=greenhill.hpalace.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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_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:326628 Archived-At: On 2024-12-11 23:04, Gerd Möllmann wrote: > Eli Zaretskii writes: > >>> Date: Thu, 12 Dec 2024 00:11:01 -0500 >>> From: Jared Finder >>> Cc: Eli Zaretskii , emacs-devel@gnu.org, >>> rudalics@gmx.at >>> >>> I think it would be good for unimplemented features to communicate >>> that >>> state to the user so users know clearly what is going on. Right now >>> the >>> error a user sees is "Can’t change the ‘minibuffer’ parameter of this >>> frame". Wouldn't it be better to have make-terminal-frame (a brand >>> new >>> function with no existing clients to support) error with something >>> like >>> "Minibuffer only frames are not supported in terminals"? >> >> I think minibuffer-only frames _are_ implemented on TTYs (albeit not >> very useful there). They are not implemented as child frames, I >> think. >> >> But yes, emitting an explicit error message about something not >> implemented would be definitely better. > > Pushed something like that to the branch. Thanks. Things otherwise seem fine with tty child frames. There's certainly oddness with mouse interaction, but it's not fundamentally broken in any way, just more things that don't work. In particular: With xterm-mouse, as I highlighted earlier, I can select the child frame even if it is set as not selectable. Once a window in a child frame is selected, I can type there normally. With gpm mouse, I have the opposite problem. I can never select the child frame and in fact the mouse behaves as if the child frame isn't there. Clicking and tooltip text both pay no attention to the child frame and just act on whatever is behind the child frame. For both of these, I couldn't get mouse-face or clicking to work on child frames. I was doing the following: (setq button (buttonize "[Click me]" (lambda (&rest _) (message "Clicked!")))) (posframe-show " *buffer*" :string (concat "A\n" button "\nB")) The posframe would show, but the mouse can't interact with the buttonized text. This may be a limitation of posframe though, it also didn't work in graphical mode. That's really it. I don't see any major issues with child frames. As long as we're ok with saying that mouse support is not mature, it seems fine to me. -- MJF