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: "Final" version of tty child frames Date: Wed, 18 Dec 2024 07:25:27 +0100 Message-ID: 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> <09b0904da92efad899865b2ece5f3116@finder.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13008"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, rudalics@gmx.at To: Jared Finder Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 18 07:26:35 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 1tNnVz-0003Ch-J5 for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Dec 2024 07:26:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNnV5-0004zI-LE; Wed, 18 Dec 2024 01:25:39 -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 1tNnUy-0004yi-Ju for emacs-devel@gnu.org; Wed, 18 Dec 2024 01:25:32 -0500 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tNnUw-0005tH-Nh; Wed, 18 Dec 2024 01:25:32 -0500 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d3e829ff44so775778a12.0; Tue, 17 Dec 2024 22:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734503129; x=1735107929; darn=gnu.org; h=content-transfer-encoding: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=jSUC54s7LQyLq5BZtD1SSNaOhU1YOHHuJvvY730zkeQ=; b=jn5lwtLwpmyFmXoGaD87qPS9MxGYHt0vPZZMpj+p8H2i7y25JK4m6J5jGTY/WHISl7 jCo1ykUQw4PIMA/vYoBd00++maphRPqFBmdXzb8uuQVTXtSS9s7bt3Rwr7ewcIg3OdAQ uIPC8aR8PoHuNt4Vr8n4cgSobVHDETFtw7gWkOquzdoqCsku69+5iT1M7rYIC2MQuvLx L6QHLuGbCktwGJgDvMvjGDy4BvBglTPombcp46BNWrfxVM/KK9eLaM0D2O38eEonU/M2 6mNQnnMBjOg76xCgbL+UrV05gfoh8B3FO67VFkfAH5v45wh/ie2F5DEI6H87BvVhLml7 htSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734503129; x=1735107929; h=content-transfer-encoding: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=jSUC54s7LQyLq5BZtD1SSNaOhU1YOHHuJvvY730zkeQ=; b=T8ff/293WfAdtTNPYN7HGafOgsU+8XzG8zoJdkB5G+gIBEVaLpmmPb2UcCYQjFklSN EsWU2Cwf7K4ZtfXrFcY+dsUMFyGZHvB6kl6j0GVfilzowQQ1ryFC8pOXKebcQKyjm1rV EDC5FDFBk/xHBtdpQjwh99JyQk5g1ZUf3DqcXb89CGuoaJM3Zw4iJVwkF6WEk79XrWK3 SD16fIZ/zIMooVI67vS9Ce91D5ieVzrTww3wYtOf7hctIhG4o8UQsvWHHSJ5nLeKeOcu MKUxBCiwOqJRj3pCV7IDiYuwleurzvUYRXzm2pdBjDCeGiHGPuZszP9lu/RAdOmTJtKM ZbHQ== X-Forwarded-Encrypted: i=1; AJvYcCWYWAvD8jKUltw4YY9GsRKZmVcnCq8WY4JMtfFahDDj+N79KKUfl9qS2E8IVb1mwXR8BL1Y+A88ZmnSTQ==@gnu.org X-Gm-Message-State: AOJu0YzD04zf0L7ZHRY7N5L6cJbde85FaCE1rXoQwnyVgq+Lw3dr23IG 33HGNjgvORqZrmShHPwoGVOUWiUDtDhiUYDhaibEHX4xRVj+0Rfdn3yQwQ== X-Gm-Gg: ASbGncu+QAuKlYxDjsAs7dYoGGqSuWFyNuKyo3PNj8hf75muQs7eh481n+SiBArsVmM 8Ro4qGgjlIXEwyEjLOnncnw3RHU7HjJaiNmHj/FNdouIBpqi+jLlhkowGSBVgXkDjVHszf3Mw8U dQuCZwju+1gwb9tUOtqLsfu4hX2/QL2qqUICcYrZcu3Zzo+6IUlR2UhfeQAcXhTefb073eZRoZa I6ff6IhQd6AuG+echktAxAre53RwUzi9Oj9o2Yx3yHKsWXfi3qlCuwarVpj4iR1F7L8xPomdV7U BOoCASC9vLVEynKVOn2O0Ocq1R638CoxNVsZ2Zte/HXetrJa0d6doYBgEj2sv/71ag== X-Google-Smtp-Source: AGHT+IGjuTdj4ckK/peHF17WxnlOMKU9Lm/OwaTIMN8iJOPZQM3F28IQqk2CUXt29yBq7TrTf0s1pA== X-Received: by 2002:a17:907:6e8e:b0:aa6:9d09:b17b with SMTP id a640c23a62f3a-aabdcc1dbbfmr496617366b.28.1734503128444; Tue, 17 Dec 2024 22:25:28 -0800 (PST) Original-Received: from pro2 (p200300e0b7267000f86be09dcd4cd505.dip0.t-ipconnect.de. [2003:e0:b726:7000:f86b:e09d:cd4c:d505]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aab963595ffsm521980266b.94.2024.12.17.22.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2024 22:25:28 -0800 (PST) In-Reply-To: <09b0904da92efad899865b2ece5f3116@finder.org> (Jared Finder's message of "Tue, 17 Dec 2024 21:35:35 -0800") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52b.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:326629 Archived-At: Jared Finder writes: > On 2024-12-11 23:04, Gerd M=C3=B6llmann wrote: >> Eli Zaretskii writes: >>=20 >>>> 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=E2=80=99t change the =E2=80=98minibuffer=E2= =80=99 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 Hi Jared, thanks for testing! And what you write is certainly true - if one wants to have child frames like on GUI, with all bells and whistles, there are probably a lot of things that await implementation :-). WRT GPM: Sounds to me like this is because GPM hasn't been changes to act analogous to xt-mouse. I think there only two commits to xt-mouse.el in the branch. It's not much, if you look at the diffs, basically only - determine the frame F under (x, y) as reported by the terminal =20=20 - Give Emacs (F, x', y'), where x' and y' are the coordinates relative to F That was all I needed, in principle, at least for xterm-mouse, to make things work. Don't know if that also fits for GPm.