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: Q: child frames on ttys Date: Sat, 31 Aug 2024 16:00:22 +0200 Message-ID: References: <86ikvz302s.fsf@gnu.org> <132fd5ff-bcdf-4d93-acab-186e52f80d9a@gmx.at> <86jzfye0hf.fsf@gnu.org> <86ikvgc3gz.fsf@gnu.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="6213"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 31 16:01: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 1skOfc-0001Sx-2z for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Aug 2024 16:01:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1skOeX-0002a6-BC; Sat, 31 Aug 2024 10:00:33 -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 1skOeU-0002Zr-Fo for emacs-devel@gnu.org; Sat, 31 Aug 2024 10:00:32 -0400 Original-Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1skOeS-0006zX-NL; Sat, 31 Aug 2024 10:00:30 -0400 Original-Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a86b64ebd8aso174169566b.1; Sat, 31 Aug 2024 07:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725112825; x=1725717625; 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=gypP2X4qhwCIKMAx2QCzssy9Ye02Myfj+y7TQHS63BM=; b=nGskuZd215MUjV7wxSNPaXrIPhGkAwMR6RhdRKN7aZYc9q0+rwub4rLUkGUuf4xQaR pzt7FlNXvuFzp5JLnYSwkFOsBoxySDRUj9y7phmzBH3/fd4lV3q/6wGW3CMzkRm7K0rt VN91o7MeWv4oo/IE++0mT1/JTcls9eanz3rY7Tp8fVOAQy84XMnQN5WMzn4BKB/NC/wa 2X3yij35UVWVRu4LsuhcILL2aRj+ujI+8kj3v6jR2onJff+qOiUHRTZc58ec3zvspm7z OzTGqVHifkd8H9UzQhQVzRKsZI0cP2aFebXztsDHBOzxqPNdSJ/Uf8De5Dh1jp6O8sJL mYjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725112825; x=1725717625; 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=gypP2X4qhwCIKMAx2QCzssy9Ye02Myfj+y7TQHS63BM=; b=RI5m47dXfLGBAYsA7Nz/khKGmNDzjDrT5w4k0i1pqGCmF04Pmx5iknGKzahme5fMEv 8hQbgQBmJT2oJtzO78MFPHQTlWwweo2hU3HgMdSvxJ0B6HTY6+SWS/Hegi8JslyIH+d6 G0UxXDXZP8D/bV35YfvMWufrdjaZhCo1N9yfTZfbxyLSAYcQRxRP05PFcdC6iwgrifV4 4OAtog1aCbPVsR3Mxech8LJAoAFXQuhjNaZ/djP9gtX11WJLgalJWKXBIcZq9u6zh+2x /llB0/gbti33B/G0cNkktxXXNx+YGpCRGLmoljOWInKnw5FMPWZAU/HhVbow9M4JljZU aN9w== X-Forwarded-Encrypted: i=1; AJvYcCW7HZa7xBfc3HytQqhq5XOK33hVHTw59+Guc64DqnpUBTNM9596vGLrAzxOC2Ou1D6oFGHCj3Km2s5atg==@gnu.org X-Gm-Message-State: AOJu0Yw0uwkP+FE0ZtuODs7U7bF/cTb2P6QS1JPD6mi3ArB2SJKjX2jV 5w6X7Z2RNYaoZWYoMJKqLJMIgdzmYAqfKQTYr0Gm2rJu/THjQIAg1N/k1w== X-Google-Smtp-Source: AGHT+IFF+AktSwGSP7+DvXZsXSXR8lIhJxWUnNX9NWyK846acjFupky34iCBIVKvjec6ITmL+d4QKA== X-Received: by 2002:a05:6402:1ecb:b0:5c2:4f68:6241 with SMTP id 4fb4d7f45d1cf-5c24f689984mr224173a12.30.1725112825084; Sat, 31 Aug 2024 07:00:25 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e3624a.dip0.t-ipconnect.de. [217.227.98.74]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c24e5f0aa2sm251650a12.85.2024.08.31.07.00.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Aug 2024 07:00:23 -0700 (PDT) In-Reply-To: <86ikvgc3gz.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 31 Aug 2024 14:54:20 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::630; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x630.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, T_SCC_BODY_TEXT_LINE=-0.01 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:323238 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: martin rudalics , emacs-devel@gnu.org >> Date: Sat, 31 Aug 2024 10:26:23 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> > From where I stand, features that are perhaps hard to implement for >> > child frames on TTY displays could be documented as unsupported, and >> > could either do nothing or signal an error. IOW, we don't have to >> > support everything on TTY frames in this regard, if doing so is >> > currently hard or impossible. The feature, even if limited, is still >> > useful enough, from my POV. >>=20 >> I think I have such a possible restriction where I'm aplit if it >> would be acceptable or rather not: Suppose one could not change named >> faces on tty chld frames. That is, for example, child frames would >> always use the same default, mode-line, etc face as the root frame. And >> as a consequence, the color frame params would have no effect. >>=20 >> The reason for that is that I copy struct glyphs from child matrices to >> the root matrix. Glyphs contain face ids, so there needs to be a >> function mapping face ids of the child frame to face ids on the root >> frame. >>=20 >> The simplest such function is of course the identity function, which >> means child and root share the same face cache. With the consequence >> that changing named faces on the child modifies faces of the root. Not >> nice, but simple. >>=20 >> As I said, I'm not sure about this. I could also think of redefining the >> concept of face id to something containing the frame or cache holding >> the face's definition. Which could be done in more than one way. And so >> on, but it's certainly some work. >>=20 >> What do people think? > > FWIW, I don't see why this would be a serious limitation. After all, > by default we define the faces identically on all frames, and Lisp > programs that want to have different faces on different frames need to > actively opt in. Most don't. Thanks. I think I'm mostly concerned of the seemingly harmless background-color frame parm, and what else there is which change the default face on a frame. I could imagine that one would want to do that for child frames. Like a frame for completion candidates, for example. Hm. I think I'll leave that as is for now, i.e. simply share the face cache with the root. It could be changed later, and it's pretty independent of the rest, I'd say. At least as far as I can see now.