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 10:26:23 +0200 Message-ID: References: <86ikvz302s.fsf@gnu.org> <132fd5ff-bcdf-4d93-acab-186e52f80d9a@gmx.at> <86jzfye0hf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14388"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: martin rudalics , 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 10:27:10 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 1skJRt-0003bV-Ow for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Aug 2024 10:27:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1skJRF-0003Qo-Ot; Sat, 31 Aug 2024 04:26:29 -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 1skJRF-0003Qb-31 for emacs-devel@gnu.org; Sat, 31 Aug 2024 04:26:29 -0400 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1skJRD-0000dJ-F7; Sat, 31 Aug 2024 04:26:28 -0400 Original-Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-371a13c7c80so2213349f8f.0; Sat, 31 Aug 2024 01:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725092785; x=1725697585; 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=D5Uo39fp6XfQhA0MVwoSXsNxLw4ICqd6wtz2WW9yqts=; b=GB+pRqfY0KN4UWLWRiH+p29lSmgoBT1TmVsGhQv80F/30OInVRKmr62+AM0u5cnhMt 8grFYmCgHSYFnlCI2RyGi9SkgaKyNqmxIwzRAqrj1nieDjWw090TKgZ11TDA8TMJrC7S PPaUHxXwPpw7WRUdw9ko6Iw0e6RdWfBKC2aGaHIj4rJEOVEQR/B22YMdf1WqtHzB/FD7 ACKfWBHOj1DZFSpIIVt7WiDmGxrlq3v7udD136hc8HACCG3jPI4Fyp/uWG+USE/7W4Qv FOaKGmDZis5ic5xia1DdbyD0JKVLd2tv7yt8HYWxrhzg5xaYhflQ8Hx6TOuGefQ3TFy3 c7DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725092785; x=1725697585; 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=D5Uo39fp6XfQhA0MVwoSXsNxLw4ICqd6wtz2WW9yqts=; b=HVTpCpBMTFYxgrgy7n9zGybxnjFVTYMYXVyUHtPBNtX1vwKtp+nil9Y15f4ffMtsVP uwTt36iPu7doCxUaz5ZvHUPD/n29YJUR6UAiBEe558sUcnD7Myz8kM0IvmeEv5d4ZKZp IBePP0NQBfIDP736ZgdVi7xqVPttEAsD9IgZrN4RXhQ6mssjRp4gRsLd5l1j8UmWXpNF VmbQObspivkV75gG9oTezNecDGhhUCBevh9SGzA30e1rLbvjRcjd6M53TUctUBJI4Ihm 8biP6pr0pw1UDwZj5FmvL6mOtBwNb8YHUggqH7XRrPz3MXSNqH9CY5VIeUKz5TfAmUeO Rqjg== X-Forwarded-Encrypted: i=1; AJvYcCWeMvBIlLtdbNIkH/nHSUdXYi+I6lEJOPUsrgtCVUc4w07QJEeosJQ+61+Q2xwMHE1vomSHooblERVSKQ==@gnu.org X-Gm-Message-State: AOJu0YxOUlF5YkEM8sNpO38EhXVqfV41whWptOcWTo9sZ8dtZg5eUiES AbGsf/xX4pFvvSgv/96as+Q+riKPw61+25kojDPBQl6+ktoYxwX89HTYHw== X-Google-Smtp-Source: AGHT+IGkm4jAfxD/mv/y2ax4Zf8O7xl81G2y60koE75njUDY2A4W5FOA3PJRsi5MhpLqob0yVg9tYA== X-Received: by 2002:a5d:5f43:0:b0:374:c21a:9dd4 with SMTP id ffacd0b85a97d-374c21a9fd5mr342708f8f.20.1725092784449; Sat, 31 Aug 2024 01:26:24 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e3624a.dip0.t-ipconnect.de. [217.227.98.74]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3749ee5080asm6079996f8f.18.2024.08.31.01.26.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Aug 2024 01:26:24 -0700 (PDT) In-Reply-To: <86jzfye0hf.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 30 Aug 2024 14:03:40 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=gerd.moellmann@gmail.com; helo=mail-wr1-x433.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:323232 Archived-At: Eli Zaretskii writes: >> Date: Fri, 30 Aug 2024 11:17:12 +0200 >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> From: martin rudalics >> >> > (Background is of course that I'm trying to assess how much work is >> > ahead, and if I want to do it :-). >> >> I suppose that visibility and restacking of child frames and size >> changes of child frames and their ancestors are the corner issues. Once >> these have been resolved, the code should be pushed and you should wait >> for user feedback. >> >> Many thanks for lifting the "Note that child frames are meaningful on >> graphical terminals only." restriction, martin > > Another feature to test with child frames on TTY displays is menus, > both from the menu bar and popup menus. > > 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. 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. 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. 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. 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. What do people think?