Q: child frames on ttys

Q: child frames on ttys

[Gerd Möllmann]

Is someone working on child frames for ttys, or has it been worked on in
the past, maybe?

I'm asking because I'm in the process of switching to tty Emacs on
macOS, and the only thing I'm missing it seems is child frames, for
Corfu, Vertico, and Transient, in my case, the latter two via Posframe.

Re: Q: child frames on ttys

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sat, 17 Aug 2024 09:24:09 +0200
> 
> Is someone working on child frames for ttys, or has it been worked on in
> the past, maybe?
> 
> I'm asking because I'm in the process of switching to tty Emacs on
> macOS, and the only thing I'm missing it seems is child frames, for
> Corfu, Vertico, and Transient, in my case, the latter two via Posframe.

I don't think it's being worked on, but Martin (CC'ed) will have more
info.

Re: Q: child frames on ttys

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Sat, 17 Aug 2024 09:24:09 +0200
>> 
>> Is someone working on child frames for ttys, or has it been worked on in
>> the past, maybe?
>> 
>> I'm asking because I'm in the process of switching to tty Emacs on
>> macOS, and the only thing I'm missing it seems is child frames, for
>> Corfu, Vertico, and Transient, in my case, the latter two via Posframe.
>
> I don't think it's being worked on, but Martin (CC'ed) will have more
> info.

Thanks.

Re: Q: child frames on ttys

[martin rudalics]

 >> Is someone working on child frames for ttys, or has it been worked on in
 >> the past, maybe?
 >>
 >> I'm asking because I'm in the process of switching to tty Emacs on
 >> macOS, and the only thing I'm missing it seems is child frames, for
 >> Corfu, Vertico, and Transient, in my case, the latter two via Posframe.
 >
 > I don't think it's being worked on, but Martin (CC'ed) will have more
 > info.

It was discussed in some length in a thread "Implementing child frames
on terminal" starting here

https://lists.nongnu.org/archive/html/emacs-devel/2022-07/msg00301.html

but IIRC nothing ever came out of it.

martin

Re: Q: child frames on ttys

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>>> Is someone working on child frames for ttys, or has it been worked on in
>>> the past, maybe?
>>>
>>> I'm asking because I'm in the process of switching to tty Emacs on
>>> macOS, and the only thing I'm missing it seems is child frames, for
>>> Corfu, Vertico, and Transient, in my case, the latter two via Posframe.
>>
>> I don't think it's being worked on, but Martin (CC'ed) will have more
>> info.
>
> It was discussed in some length in a thread "Implementing child frames
> on terminal" starting here
>
> https://lists.nongnu.org/archive/html/emacs-devel/2022-07/msg00301.html
>
> but IIRC nothing ever came out of it.
>
> martin

Thanks for the pointer, Martin!

Re: Q: child frames on ttys

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> It was discussed in some length in a thread "Implementing child frames
>> on terminal" starting here
>>
>> https://lists.nongnu.org/archive/html/emacs-devel/2022-07/msg00301.html
>>
>> but IIRC nothing ever came out of it.
>>
>> martin
>
> Thanks for the pointer, Martin!

I've taken a look today, and I think the tty stuff is in principle still
like it was when I wrote it, plus some additions like multi-tty of
course.

Anyway, I think the below would be a viable plan how to add child frames
for ttys. Or a very rough first approach.

Any comments? Did I overlook something important?

* What we have

Child frames are created with the =parent-frame= frame parameter on
GUIs. This parameter can be changed at any time to create a hierarchy
of child fremes. It can be reset to make a frame a non-child frame.

A terminal's =tty_display_info= contains a =top_frame= member which is the
topmost frame in z-order, where z-order is a bit misleading because
all frames currently occupy the whole terminal screen. IOW making a
frame the topmost frame obsures all other frames.

Redisplay considers topmost frames only (more than one for multiple
terminals).

The function =frame-restack= can be used to change the z-order of
frames. It currently does not handle tty frames.

=frame-list= contains child frames.

* Terminology

A =root frame= is a frame with no parent frame. It always occupies the
whole terminal.

* Steps

1. Let frames have arbitrary ~(x, y, w, h)~ except for root frames,
   which have ~(0, 0, terminal-width, terminal-height)~. Change
   =frame-geometry=.

2. Give root frames a =child_frames= list which is in z-order, topmost
   last. Add a =tty-frame-restack= which acts on this list.

3. In =redisplay_internal=, act only on root frames. Generating desired
   glyphs generates glyphs for the root frame, then child frames in
   z-order, topmost last, i.e. in the order of =frame::child_frames=.

4. Making a frame visible means making all children frames visible.

5. Do not clear the terminal, unless switching to another root frame.

6. Update: Build frame matrices for all windows visible on a terminal.
   Copy visible parts of child fraem desired glyphs to root frame
   desired glyphs. Then write to the screen.

7. After writing to the screen, copy visble parts of root frame
   current glyphs to current glyphs of children.

8. Add something like =ns-frame-list-z-order= for ttys.

* Don't

1. Allocate child frame glyphs from a common pool. Reason is clipping.
   Don't want to change glyph generation in redisplay to take clipping
   into account. It's not worth the effort.

Re: Q: child frames on ttys

[martin rudalics]

 > 4. Making a frame visible means making all children frames visible.

With the obvious exception that a child frame whose visibility is off
should not be considered.  IIUC most applications show child frames only
for a short period of time and make them invisible as soon as the user
reacts in some way or restarts typing.

 > 6. Update: Build frame matrices for all windows visible on a terminal.
 >     Copy visible parts of child fraem desired glyphs to root frame
 >     desired glyphs. Then write to the screen.
 >
 > 7. After writing to the screen, copy visble parts of root frame
 >     current glyphs to current glyphs of children.

What does the current glyph matrix of the root frame contain now?  The
overwritten parts or the original ones?  Or are the original parts
stashed away so they can be easily reused when the child frame is made
invisible?

martin

Re: Q: child frames on ttys

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> 4. Making a frame visible means making all children frames visible.
>
> With the obvious exception that a child frame whose visibility is off
> should not be considered.  IIUC most applications show child frames only
> for a short period of time and make them invisible as soon as the user
> reacts in some way or restarts typing.

Thanks, that's true.

>
>> 6. Update: Build frame matrices for all windows visible on a terminal.
>>     Copy visible parts of child fraem desired glyphs to root frame
>>     desired glyphs. Then write to the screen.
>>
>> 7. After writing to the screen, copy visble parts of root frame
>>     current glyphs to current glyphs of children.
>
> What does the current glyph matrix of the root frame contain now?  The
> overwritten parts or the original ones?  Or are the original parts
> stashed away so they can be easily reused when the child frame is made
> invisible?

The curren matrix of the root frame must always reflect what is on the
screen, so that we can decide what to output to the terminal to make the
terminal display what the desired matrix says. IOW, the parts of the
root frame's current matrix that were overwritten don't really
interest anymore.

Re: Q: child frames on ttys

[Robert Pluim]

>>>>> On Wed, 21 Aug 2024 10:03:33 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:
    >> 
    >>> 6. Update: Build frame matrices for all windows visible on a terminal.
    >>> Copy visible parts of child fraem desired glyphs to root frame
    >>> desired glyphs. Then write to the screen.
    >>> 
    >>> 7. After writing to the screen, copy visble parts of root frame
    >>> current glyphs to current glyphs of children.
    >> 
    >> What does the current glyph matrix of the root frame contain now?  The
    >> overwritten parts or the original ones?  Or are the original parts
    >> stashed away so they can be easily reused when the child frame is made
    >> invisible?

    Gerd> The curren matrix of the root frame must always reflect what is on the
    Gerd> screen, so that we can decide what to output to the terminal to make the
    Gerd> terminal display what the desired matrix says. IOW, the parts of the
    Gerd> root frame's current matrix that were overwritten don't really
    Gerd> interest anymore.

Donʼt tty menus already do this? Perhaps we could reuse them.

Robert
-- 

Re: Q: child frames on ttys

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Wed, 21 Aug 2024 10:03:33 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:
>     >> 
>     >>> 6. Update: Build frame matrices for all windows visible on a terminal.
>     >>> Copy visible parts of child fraem desired glyphs to root frame
>     >>> desired glyphs. Then write to the screen.
>     >>> 
>     >>> 7. After writing to the screen, copy visble parts of root frame
>     >>> current glyphs to current glyphs of children.
>     >> 
>     >> What does the current glyph matrix of the root frame contain now?  The
>     >> overwritten parts or the original ones?  Or are the original parts
>     >> stashed away so they can be easily reused when the child frame is made
>     >> invisible?
>
>     Gerd> The curren matrix of the root frame must always reflect what is on the
>     Gerd> screen, so that we can decide what to output to the terminal to make the
>     Gerd> terminal display what the desired matrix says. IOW, the parts of the
>     Gerd> root frame's current matrix that were overwritten don't really
>     Gerd> interest anymore.
>
> Donʼt tty menus already do this? Perhaps we could reuse them.

I think the tty menus work a bit different from what I'm thinking of. I
must admit that I haven't looked very closely, and I'm just assuming
that it works like what I've talked about with Eli a long time ago.

If that's the case, menus panes temporarily save away some part of the
matrix, and restore it when done with the eseentially modal interaction
with the menu. Soemthing like that. I think it's a pretty different use
case.

The mechanism could in principle be used to pop something up on ttys of
course, but that wouldn't help much with existing packages that use
child frames already, like Corfu or Posframe.

Re: Q: child frames on ttys

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> * What we have
>
> Child frames are created with the =parent-frame= frame parameter on
> GUIs. This parameter can be changed at any time to create a hierarchy
> of child fremes. It can be reset to make a frame a non-child frame.
>
> A terminal's =tty_display_info= contains a =top_frame= member which is the
> topmost frame in z-order, where z-order is a bit misleading because
> all frames currently occupy the whole terminal screen. IOW making a
> frame the topmost frame obsures all other frames.
>
> Redisplay considers topmost frames only (more than one for multiple
> terminals).
>
> The function =frame-restack= can be used to change the z-order of
> frames. It currently does not handle tty frames.
>
> =frame-list= contains child frames.
>
> * Terminology
>
> A =root frame= is a frame with no parent frame. It always occupies the
> whole terminal.
>
> * Steps
>
> 1. Let frames have arbitrary ~(x, y, w, h)~ except for root frames,
>    which have ~(0, 0, terminal-width, terminal-height)~. Change
>    =frame-geometry=.
>
> 2. Give root frames a =child_frames= list which is in z-order, topmost
>    last. Add a =tty-frame-restack= which acts on this list.
>
> 3. In =redisplay_internal=, act only on root frames. Generating desired
>    glyphs generates glyphs for the root frame, then child frames in
>    z-order, topmost last, i.e. in the order of =frame::child_frames=.
>
> 4. Making a frame visible means making all children frames visible.
>
> 5. Do not clear the terminal, unless switching to another root frame.
>
> 6. Update: Build frame matrices for all windows visible on a terminal.
>    Copy visible parts of child fraem desired glyphs to root frame
>    desired glyphs. Then write to the screen.
>
> 7. After writing to the screen, copy visble parts of root frame
>    current glyphs to current glyphs of children.

Changed this to:

7. After writing to the screen, for all child frames that were
   displayed, update current matrices from desired matrices. There is
   no need to copy glyphs from the root frame since we have them already in
   the desired matrix.

> 8. Add something like =ns-frame-list-z-order= for ttys.
>
> * Don't
>
> 1. Allocate child frame glyphs from a common pool. Reason is clipping.
>    Don't want to change glyph generation in redisplay to take clipping
>    into account. It's not worth the effort.

Re: Q: child frames on ttys

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> * What we have
>>
>> Child frames are created with the =parent-frame= frame parameter on
>> GUIs. This parameter can be changed at any time to create a hierarchy
>> of child fremes. It can be reset to make a frame a non-child frame.
>>
>> A terminal's =tty_display_info= contains a =top_frame= member which is the
>> topmost frame in z-order, where z-order is a bit misleading because
>> all frames currently occupy the whole terminal screen. IOW making a
>> frame the topmost frame obsures all other frames.
>>
>> Redisplay considers topmost frames only (more than one for multiple
>> terminals).
>>
>> The function =frame-restack= can be used to change the z-order of
>> frames. It currently does not handle tty frames.
>>
>> =frame-list= contains child frames.
>>
>> * Terminology
>>
>> A =root frame= is a frame with no parent frame. It always occupies the
>> whole terminal.
>>
>> * Steps
>>
>> 1. Let frames have arbitrary ~(x, y, w, h)~ except for root frames,
>>    which have ~(0, 0, terminal-width, terminal-height)~. Change
>>    =frame-geometry=.
>>
>> 2. Give root frames a =child_frames= list which is in z-order, topmost
>>    last. Add a =tty-frame-restack= which acts on this list.
>>
>> 3. In =redisplay_internal=, act only on root frames. Generating desired
>>    glyphs generates glyphs for the root frame, then child frames in
>>    z-order, topmost last, i.e. in the order of =frame::child_frames=.
>>
>> 4. Making a frame visible means making all children frames visible.
>>
>> 5. Do not clear the terminal, unless switching to another root frame.
>>
>> 6. Update: Build frame matrices for all windows visible on a terminal.
>>    Copy visible parts of child fraem desired glyphs to root frame
>>    desired glyphs. Then write to the screen.
>>
>> 7. After writing to the screen, copy visble parts of root frame
>>    current glyphs to current glyphs of children.
>
> Changed this to:
>
> 7. After writing to the screen, for all child frames that were
>    displayed, update current matrices from desired matrices. There is
>    no need to copy glyphs from the root frame since we have them already in
>    the desired matrix.
>
>> 8. Add something like =ns-frame-list-z-order= for ttys.
>>
>> * Don't
>>
>> 1. Allocate child frame glyphs from a common pool. Reason is clipping.
>>    Don't want to change glyph generation in redisplay to take clipping
>>    into account. It's not worth the effort.

So, this seems to work, at least in principle. Where in principle means
I didn't try much yet, but it looks like I can at least display
overlapping child frames.


[-- Attachment #2: Screenshot 2024-08-30 at 08.40.01.png --]
[-- Type: image/png, Size: 479492 bytes --]

[-- Attachment #3: Type: text/plain, Size: 528 bytes --]


I have a question regarding the child frame feature in general though.

As I said before, I want to use them for Corfu and Posframe, the latter
with Vertico and Transient. But the child frame feature looks like
something much more general, more like a general MDI feature, as opposed
to SDI. And my question is: Is that actually used somewhere? In some
package, or in Emacs itself? If it is, I'd be grateful for a pointer.

(Background is of course that I'm trying to assess how much work is
ahead, and if I want to do it :-).

Re: Q: child frames on ttys

[martin rudalics]

 > So, this seems to work, at least in principle. Where in principle means
 > I didn't try much yet, but it looks like I can at least display
 > overlapping child frames.

The screenshot looks good.  The question is how much resources it takes
to turn the visibility of child frames on and off.  I conjecture that
restoring the original frame glyph matrix could/should be even cheaper
than handling the corresponding expose events on graphic frames.

I wonder whether you should invariably show truncation/continuation
columns on child frames and give them a same background as line numbers,
title bars and modelines to make the child frame stand out more against
the overlapped frame.  At least optionally.

 > I have a question regarding the child frame feature in general though.
 >
 > As I said before, I want to use them for Corfu and Posframe, the latter
 > with Vertico and Transient. But the child frame feature looks like
 > something much more general, more like a general MDI feature, as opposed
 > to SDI. And my question is: Is that actually used somewhere? In some
 > package, or in Emacs itself? If it is, I'd be grateful for a pointer.

Initially, I wrote the child frame code because I found the necessary
APIs for Windows and X and planned to use them for tooltips.  Later I
found out that they are not really useful for that purpose because on
graphic displays tooltips are often displayed outside the parent frame
while child frames are clipped.  Moreover, tooltips usually disappear
when the user interacts in some way and the major advantage of child
frames - namely that they move together with their parent - gets lost in
practice.  I even spent some time on 'window-largest-empty-rectangle' to
avoid that tooltips hide any normal text.  Currently, I'm still using
normal frames for tooltips while I'm using child frames mostly for
displaying the minibuffer.

Child frames can be used to overcome the classic restriction that Emacs
windows are "tiled".  'display-buffer-in-child-frame' conceptually
provides that feature.  But I don't see why that would need any special
treatment on TTYs.  Why do you think that MDI vs SDI would impact the
design of child frames on TTYs?

 > (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

Re: Q: child frames on ttys

[Eli Zaretskii]

> Date: Fri, 30 Aug 2024 11:17:12 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > (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.

Thanks.

Re: Q: child frames on ttys

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 30 Aug 2024 11:17:12 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>> 
>>  > (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.

Yes, thanks for the hint. Also, dialogs are probably also affected in
some way.

> 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.

Thanks, I'll keep that in mind.

Re: Q: child frames on ttys

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>,  emacs-devel@gnu.org
> Date: Fri, 30 Aug 2024 13:23:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Another feature to test with child frames on TTY displays is menus,
> > both from the menu bar and popup menus.
> 
> Yes, thanks for the hint. Also, dialogs are probably also affected in
> some way.

Dialogs are implemented with popup menus on TTY frames.

Re: Q: child frames on ttys

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 30 Aug 2024 11:17:12 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>>
>>  > (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?

Re: Q: child frames on ttys

[Eli Zaretskii]

> 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.

Re: Q: child frames on ttys

[Gerd Möllmann]

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.

Re: Q: child frames on ttys

[Eli Zaretskii]

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

We should document that this doesn't work on TTY displays, and let
applications deal with that.

> 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.

Right.  Just please don't forget documenting it.

Re: Q: child frames on ttys

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
>> Date: Sat, 31 Aug 2024 16:00:22 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 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.
>
> We should document that this doesn't work on TTY displays, and let
> applications deal with that.
>
>> 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.
>
> Right.  Just please don't forget documenting it.

Just wanted to mention that I had an idea yesterday how to solve that
problem without making broad changes outside of the tty code. The idea
is to write a function that maps an (x, y) position in a
matrix the frame holding the realized face at that position.

One ugly difference less between ttys and GUI.

Re: Q: child frames on ttys

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Mon, 02 Sep 2024 10:37:37 +0200
> 
> Just wanted to mention that I had an idea yesterday how to solve that
> problem without making broad changes outside of the tty code. The idea
> is to write a function that maps an (x, y) position in a
> matrix the frame holding the realized face at that position.

Sorry, I don't understand: a function mapping a position to what?
'struct face'?  If so, and unless the function is cheap enough,
wouldn't that make redisplay slower?

Re: Q: child frames on ttys

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
>> Date: Mon, 02 Sep 2024 10:37:37 +0200
>> 
>> Just wanted to mention that I had an idea yesterday how to solve that
>> problem without making broad changes outside of the tty code. The idea
>> is to write a function that maps an (x, y) position in a
>> matrix the frame holding the realized face at that position.
>
> Sorry, I don't understand: a function mapping a position to what?
> 'struct face'?  If so, and unless the function is cheap enough,
> wouldn't that make redisplay slower?

Yes, in th4 end it's a struct face, that's right. And it's pretty cheap.
Of course famous last words and so on. I haven't implemented it yet.
And it affects tty frames only which I find nice.

The thing is intended to work like this:

Suppose we have only one root frame and a number of overlapping child
frames on top of it. All these frames are considered independent of each
other like on a GUI. Each frame has its own frame matrices.

For each frame we build window matrices as usual, and for each frame we
build the corresponding frame matrix.

New is building the frame matrix and writing to the terminal are
separated from each other. Writing to the terminal happens only for the
root frame, after first combining all the frame matrices we deal with by
copying glyphs from the child matrices, in reverse z-order.

The combination step computes z-order and the intersection rectangles of
child frames with the root frame to know what to copy where. That's how
I do it now.

The new plan is to record these rectangles as a list of (child-frame
rectangle). Probably not Lisp lists, don't know.

Now, when writing glyphs at some cursor position (x y), we call
turn_on_face (frame, face_id), where face_id comes from some glyph. We
consult the list above, and determine the topmost in z-order child-frame
from which this glyph was copied, if it was. That frame contans the face
cache for the face_id of the glyph. 

When there are no child frames, the list is empty, and it boils down to
a function call instead of simply using FACE_FROM_ID. I'd say that's
cheap.

If there are N child frames, we have to test N times in the worst case
if (x y) in inside a given rectangle, which is 4 integer comparisions
each. And N will be small, typically N = 1.

Seems workable to me, but one has to wait and see of course.

Re: Q: child frames on ttys

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Mon, 02 Sep 2024 14:46:11 +0200
> 
> The new plan is to record these rectangles as a list of (child-frame
> rectangle). Probably not Lisp lists, don't know.

Why not simply record the pointer to 'struct frame" inside the glyph
structure, to indicate which frame it came from?  Then you can call
FACE_FROM_ID like we do now, because that macro already accepts the
frame pointer.  We could have a convention that NULL as the frame
pointer means the root frame or something.

Re: Q: child frames on ttys

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
>> Date: Mon, 02 Sep 2024 14:46:11 +0200
>> 
>> The new plan is to record these rectangles as a list of (child-frame
>> rectangle). Probably not Lisp lists, don't know.
>
> Why not simply record the pointer to 'struct frame" inside the glyph
> structure, to indicate which frame it came from?  Then you can call
> FACE_FROM_ID like we do now, because that macro already accepts the
> frame pointer.  We could have a convention that NULL as the frame
> pointer means the root frame or something.

Yes, that would be an alternative.

I'm not feeling comfortable with it for a mixture of reasons

- glyph::frame wouldn't be useful for anything but tty child frames
- it makes struct glyph larger
- it's a less localized
- the info is already available, I only need to record it

Let's see. If it's too slow (I doubt it), one could try that or
something similar.

Re: Q: child frames on ttys

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> So, this seems to work, at least in principle. Where in principle means
>> I didn't try much yet, but it looks like I can at least display
>> overlapping child frames.
>
> The screenshot looks good.  The question is how much resources it takes
> to turn the visibility of child frames on and off.  I conjecture that
> restoring the original frame glyph matrix could/should be even cheaper
> than handling the corresponding expose events on graphic frames.

Hard to tell if it's cheaper than on GUIs, but my gut feeling is that it
won't be too expensive. But it remains to be seen, I'm not yet that far.

> I wonder whether you should invariably show truncation/continuation
> columns on child frames and give them a same background as line numbers,
> title bars and modelines to make the child frame stand out more against
> the overlapped frame.  At least optionally.

Yeah, that's also still open. I'd like if background-color and
foreground-color frame params did something reasonable, at least on
child frames.

And I think I'd also like to have optional frame borders,
with border-width or something. Something lile +-| with display table
entries for the edges, sides, and horizontal lines.

>> I have a question regarding the child frame feature in general though.
>>
>> As I said before, I want to use them for Corfu and Posframe, the latter
>> with Vertico and Transient. But the child frame feature looks like
>> something much more general, more like a general MDI feature, as opposed
>> to SDI. And my question is: Is that actually used somewhere? In some
>> package, or in Emacs itself? If it is, I'd be grateful for a pointer.
>
> Initially, I wrote the child frame code because I found the necessary
> APIs for Windows and X and planned to use them for tooltips.  Later I
> found out that they are not really useful for that purpose because on
> graphic displays tooltips are often displayed outside the parent frame
> while child frames are clipped.  Moreover, tooltips usually disappear
> when the user interacts in some way and the major advantage of child
> frames - namely that they move together with their parent - gets lost in
> practice.  I even spent some time on 'window-largest-empty-rectangle' to
> avoid that tooltips hide any normal text.  Currently, I'm still using
> normal frames for tooltips while I'm using child frames mostly for
> displaying the minibuffer.

Hm, okay. Thanks for the insight.

> Child frames can be used to overcome the classic restriction that Emacs
> windows are "tiled".  'display-buffer-in-child-frame' conceptually
> provides that feature.  But I don't see why that would need any special
> treatment on TTYs.  Why do you think that MDI vs SDI would impact the
> design of child frames on TTYs?

It wouldn't impact the design, I think. What I'm thinking of is
basically if I can get by supporting only what I really need for Corfu
and Posframe (+ Vertico + Transient), and nothing more, without
implementing the whole thing.

>> (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.

That's one thing. Another big one is the silent assumptioin that on ttys
there exists only one visible frame and that frame occupies the whole
terminal. Hard to find and pops up again and again. 

> Once these have been resolved, the code should be pushed and you
> should wait for user feedback.

It is already pushed, but to a branch in my fork :-).

Anyway, this can take a bit.

Re: Q: child frames on ttys

[Robert Pluim]

>>>>> On Fri, 30 Aug 2024 08:42:00 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:

    Gerd> I have a question regarding the child frame feature in general though.

    Gerd> As I said before, I want to use them for Corfu and Posframe, the latter
    Gerd> with Vertico and Transient. But the child frame feature looks like
    Gerd> something much more general, more like a general MDI feature, as opposed
    Gerd> to SDI. And my question is: Is that actually used somewhere? In some
    Gerd> package, or in Emacs itself? If it is, I'd be grateful for a pointer.

I donʼt know what MDI vs SDI is, but I have a use case in mind where I
have two non-overlapping frames in the same tty. Is that the kind of
thing youʼre talking about?

Robert
-- 

Re: Q: child frames on ttys

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 30 Aug 2024 08:42:00 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:
>
>     Gerd> I have a question regarding the child frame feature in general though.
>
>     Gerd> As I said before, I want to use them for Corfu and Posframe, the latter
>     Gerd> with Vertico and Transient. But the child frame feature looks like
>     Gerd> something much more general, more like a general MDI feature, as opposed
>     Gerd> to SDI. And my question is: Is that actually used somewhere? In some
>     Gerd> package, or in Emacs itself? If it is, I'd be grateful for a pointer.
>
> I donʼt know what MDI vs SDI is, 

(MDI is "Multi-" and SDI "Single-" Document Interface, AFAIR. In an MDI
applicaton, an application main window contains a child window for each
document opened in the application. With SDI, an independent window
opens for each document, and there is no main application window.
Something like that. And I haven't seen an MDI application for some time
now, I think.)

> but I have a use case in mind where I have two non-overlapping frames
> in the same tty. Is that the kind of thing youʼre talking about?

Would these be "normal" Emacs frames like one gets with C-x 5 2? Or are
these frames special in some sense, like a Corfu child frame displaying
completions (possibly with second child frame displaying additional info
for completion candidates), or a Posframe chlid frame displaying a
Transient menu, or somehting like that?

Re: Q: child frames on ttys

[Robert Pluim]

>>>>> On Fri, 30 Aug 2024 13:19:44 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:
    >> but I have a use case in mind where I have two non-overlapping frames
    >> in the same tty. Is that the kind of thing youʼre talking about?

    Gerd> Would these be "normal" Emacs frames like one gets with C-x 5 2? Or are
    Gerd> these frames special in some sense, like a Corfu child frame displaying
    Gerd> completions (possibly with second child frame displaying additional info
    Gerd> for completion candidates), or a Posframe chlid frame displaying a
    Gerd> Transient menu, or somehting like that?

Theyʼd be completely normal independent frames. Think two half screen
gui frames aligned next to each other, but then on a tty.

If there was a way in Emacs to tell window generating commands to
pretend that only the left half of the current tty frame should be
considered, then I could use that, but I donʼt know of one. (hmm,
could I spike `frame-width' somehow?)

(itʼs an obscure use case, so itʼs really not a big deal if itʼs not
supported. posframe or similar on tty would already be fantastic)

Robert
-- 

Re: Q: child frames on ttys

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 30 Aug 2024 13:19:44 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:
>     >> but I have a use case in mind where I have two non-overlapping frames
>     >> in the same tty. Is that the kind of thing youʼre talking about?
>
>     Gerd> Would these be "normal" Emacs frames like one gets with C-x 5 2? Or are
>     Gerd> these frames special in some sense, like a Corfu child frame displaying
>     Gerd> completions (possibly with second child frame displaying additional info
>     Gerd> for completion candidates), or a Posframe chlid frame displaying a
>     Gerd> Transient menu, or somehting like that?
>
> Theyʼd be completely normal independent frames. Think two half screen
> gui frames aligned next to each other, but then on a tty.
>
> If there was a way in Emacs to tell window generating commands to
> pretend that only the left half of the current tty frame should be
> considered, then I could use that, but I donʼt know of one. (hmm,
> could I spike `frame-width' somehow?)
>
> (itʼs an obscure use case, so itʼs really not a big deal if itʼs not
> supported. posframe or similar on tty would already be fantastic)

Thanks, I guess that speaks for having a more or less complete child
frame feature.

Re: Q: child frames on ttys

[Dmitry Gutov]

On 17/08/2024 10:24, Gerd Möllmann wrote:
> I'm asking because I'm in the process of switching to tty Emacs on
> macOS, and the only thing I'm missing it seems is child frames, for
> Corfu, Vertico, and Transient, in my case, the latter two via Posframe.

Off topic (sorry), but I wish someone worked on child frames looking 
better under GNOME/Linux.

When I test it on macOS, it seems regular, but under GNOME it swiftly 
blinks once every refresh. Something to do with double buffering, maybe.

Re: Q: child frames on ttys

[Eli Zaretskii]

> Date: Sat, 31 Aug 2024 00:11:10 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 17/08/2024 10:24, Gerd Möllmann wrote:
> > I'm asking because I'm in the process of switching to tty Emacs on
> > macOS, and the only thing I'm missing it seems is child frames, for
> > Corfu, Vertico, and Transient, in my case, the latter two via Posframe.
> 
> Off topic (sorry), but I wish someone worked on child frames looking 
> better under GNOME/Linux.
> 
> When I test it on macOS, it seems regular, but under GNOME it swiftly 
> blinks once every refresh. Something to do with double buffering, maybe.

Do you mean that disabling double-buffering stops the blinking?

Re: Q: child frames on ttys

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 31 Aug 2024 00:11:10 +0300
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> On 17/08/2024 10:24, Gerd Möllmann wrote:
>> > I'm asking because I'm in the process of switching to tty Emacs on
>> > macOS, and the only thing I'm missing it seems is child frames, for
>> > Corfu, Vertico, and Transient, in my case, the latter two via Posframe.
>> 
>> Off topic (sorry), but I wish someone worked on child frames looking 
>> better under GNOME/Linux.
>> 
>> When I test it on macOS, it seems regular, but under GNOME it swiftly 
>> blinks once every refresh. Something to do with double buffering, maybe.
>
> Do you mean that disabling double-buffering stops the blinking?

Any issue observed with child frames should first be reproduced on a
build `--with-x-toolkit=no', or there's no eliminating the toolkit as a
suspect.

Re: Q: child frames on ttys

[Dmitry Gutov]

On 31/08/2024 11:46, Po Lu wrote:
>>> Off topic (sorry), but I wish someone worked on child frames looking
>>> better under GNOME/Linux.
>>>
>>> When I test it on macOS, it seems regular, but under GNOME it swiftly
>>> blinks once every refresh. Something to do with double buffering, maybe.
>> Do you mean that disabling double-buffering stops the blinking?
> Any issue observed with child frames should first be reproduced on a
> build `--with-x-toolkit=no', or there's no eliminating the toolkit as a
> suspect.

It's reproducible with the "no toolkit" build just the same, see the 
recording in the other email that I made with it.

Re: Q: child frames on ttys

[Dmitry Gutov]

On 01/09/2024 03:27, Dmitry Gutov wrote:
> On 31/08/2024 11:46, Po Lu wrote:
>>>> Off topic (sorry), but I wish someone worked on child frames looking
>>>> better under GNOME/Linux.
>>>>
>>>> When I test it on macOS, it seems regular, but under GNOME it swiftly
>>>> blinks once every refresh. Something to do with double buffering, 
>>>> maybe.
>>> Do you mean that disabling double-buffering stops the blinking?
>> Any issue observed with child frames should first be reproduced on a
>> build `--with-x-toolkit=no', or there's no eliminating the toolkit as a
>> suspect.
> 
> It's reproducible with the "no toolkit" build just the same, see the 
> recording in the other email that I made with it.

Correction: I see the issue with the "lucid" build, a slightly different 
visually but also buggy behavior with the "no toolkit" build (I think 
that's the one I made the video with), and actually no problem with the 
"gtk3" build (in the past the variable x-gtk-resize-child-frames was 
added as a workaround, but on my current system it does not seem to 
matter -- maybe because it's using Wayland).

The pgtk build is almost fine, but "blinks" about 1 time out of 20.

Re: Q: child frames on ttys

[Dmitry Gutov]

On 31/08/2024 09:45, Eli Zaretskii wrote:
>> Date: Sat, 31 Aug 2024 00:11:10 +0300
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 17/08/2024 10:24, Gerd Möllmann wrote:
>>> I'm asking because I'm in the process of switching to tty Emacs on
>>> macOS, and the only thing I'm missing it seems is child frames, for
>>> Corfu, Vertico, and Transient, in my case, the latter two via Posframe.
>>
>> Off topic (sorry), but I wish someone worked on child frames looking
>> better under GNOME/Linux.
>>
>> When I test it on macOS, it seems regular, but under GNOME it swiftly
>> blinks once every refresh. Something to do with double buffering, maybe.
> 
> Do you mean that disabling double-buffering stops the blinking?

Unfortunately no (I just retested with --with-xdbe=no). Just that the 
issue looks like something that stems from insufficient synchronization 
in the graphical system (inconsistent states being displayed).

To clarify, here's a video with Company popup - first (20s) with 
company-posframe-mode being on - then with it off (next 15s), and then 
again with company-posframe-mode on. That mode switches the popup 
rendering to use child frames instead of overlays. The minibuffer got 
cropped out, so the mode switching looks just like a pause when 
nothing's happening.

https://imgur.com/a/moGloQP

FWIW, I'm seeing the same issue with Corfu, so it doesn't seem to be 
specific to Company or Posframe.