Re: Q: child frames on ttys

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: martin rudalics <rudalics@gmx.at>,  emacs-devel@gnu.org
>> Date: Sat, 31 Aug 2024 10:26:23 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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?
>
> 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.