Question about üarent-frame changes

Question about üarent-frame changes

[Gerd Möllmann]

Hi Martin,

I came across another question today. Maybe you can help me with this.
It's actually not very technical, more a question if and how something
is used today, or how important it is supporting it on ttys.

I'm talking about changing the parent-frame of a frame.

AFAICT from the Elisp Info docs, one is currently free to change the
parent-frame as one sees fit. That is, one can make a child a root
frame, a root frame a child, or change the parent of a child to another
root.

I'm currently inclined to disallow parent-frame changes on ttys
entirely, unless it is used for something. Couldn't find something
today, but maybe something is a package outside Emacs' repo, or I'm just
ont looking for the right thing.

WDYT?

Re: Question about üarent-frame changes

[martin rudalics]

 > AFAICT from the Elisp Info docs, one is currently free to change the
 > parent-frame as one sees fit. That is, one can make a child a root
 > frame, a root frame a child, or change the parent of a child to another
 > root.
 >
 > I'm currently inclined to disallow parent-frame changes on ttys
 > entirely, unless it is used for something. Couldn't find something
 > today, but maybe something is a package outside Emacs' repo, or I'm just
 > ont looking for the right thing.

I'm not aware of people using multiple frames on TTYs and I have no idea
whether child frames out there are even intended to be reparented.

Reparenting is useful because you can set up one child frame for some
special purpose, make it invisible when you don't need it, and move it
to another frame and make it visible there whenever you want to.  On
GUIs, this approach has the advantage that you can avoid the (at least
here) costly process of setting up frame faces every time anew.  Emacs
tooltips do that by default and I recall that showing a tooltip every
time incurred two entire GC cycles here.

martin

Re: Question about üarent-frame changes

[Ship Mints]

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

I use multiple frames on tty just as I do with a  window system. Switching
among frames works the same and tab-bar works the same. Try it like this.
Start your emacs, C-x 5 n, M-x select-frame-by-name and you'll see two
frames.

On Wed, Sep 18, 2024 at 10:16 AM martin rudalics <rudalics@gmx.at> wrote:

>  > AFAICT from the Elisp Info docs, one is currently free to change the
>  > parent-frame as one sees fit. That is, one can make a child a root
>  > frame, a root frame a child, or change the parent of a child to another
>  > root.
>  >
>  > I'm currently inclined to disallow parent-frame changes on ttys
>  > entirely, unless it is used for something. Couldn't find something
>  > today, but maybe something is a package outside Emacs' repo, or I'm just
>  > ont looking for the right thing.
>
> I'm not aware of people using multiple frames on TTYs and I have no idea
> whether child frames out there are even intended to be reparented.
>
> Reparenting is useful because you can set up one child frame for some
> special purpose, make it invisible when you don't need it, and move it
> to another frame and make it visible there whenever you want to.  On
> GUIs, this approach has the advantage that you can avoid the (at least
> here) costly process of setting up frame faces every time anew.  Emacs
> tooltips do that by default and I recall that showing a tooltip every
> time incurred two entire GC cycles here.
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 1918 bytes --]

Re: Question about üarent-frame changes

[martin rudalics]

 > I use multiple frames on tty just as I do with a  window system. Switching
 > among frames works the same and tab-bar works the same. Try it like this.
 > Start your emacs, C-x 5 n, M-x select-frame-by-name and you'll see two
 > frames.

But not simultaneously.  Still it's good to know that people do use
multiple frames on TTYs.

Thanks, martin

Re: Question about üarent-frame changes

[Eli Zaretskii]

> Date: Wed, 18 Sep 2024 20:51:21 +0200
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  Emacs Devel <emacs-devel@gnu.org>
> From: martin rudalics <rudalics@gmx.at>
> 
> Still it's good to know that people do use multiple frames on TTYs.

Of course they do; I do.  We even have commands specifically for that
use case: select-frame-by-name.  That command only makes sense if you
have more than 2 frames on a TTY display.

Re: Question about üarent-frame changes

[martin rudalics]

 >> Still it's good to know that people do use multiple frames on TTYs.
 >
 > Of course they do; I do.  We even have commands specifically for that
 > use case: select-frame-by-name .  That command only makes sense if you
 > have more than 2 frames on a TTY display.

I never noticed that.

Thanks for the explanation, martin

Re: Question about üarent-frame changes

[Robert Pluim]

>>>>> On Wed, 18 Sep 2024 16:15:56 +0200, martin rudalics <rudalics@gmx.at> said:

    >> AFAICT from the Elisp Info docs, one is currently free to change the
    >> parent-frame as one sees fit. That is, one can make a child a root
    >> frame, a root frame a child, or change the parent of a child to another
    >> root.
    >> 
    >> I'm currently inclined to disallow parent-frame changes on ttys
    >> entirely, unless it is used for something. Couldn't find something
    >> today, but maybe something is a package outside Emacs' repo, or I'm just
    >> ont looking for the right thing.

    martin> I'm not aware of people using multiple frames on TTYs and I have no idea
    martin> whether child frames out there are even intended to be reparented.

I do it all the time. But obviously they each occupy the full
terminal.

    martin> Reparenting is useful because you can set up one child frame for some
    martin> special purpose, make it invisible when you don't need it, and move it
    martin> to another frame and make it visible there whenever you want to.  On
    martin> GUIs, this approach has the advantage that you can avoid the (at least
    martin> here) costly process of setting up frame faces every time anew.  Emacs
    martin> tooltips do that by default and I recall that showing a tooltip every
    martin> time incurred two entire GC cycles here.

Would setting up frame faces be that expensive on tty? Iʼd really love
to have tty child frames, even if they were not blazingly fast.

In any case, I took a quick look at "posframe", it doesnʼt do any
reparenting that I can see.

Robert
-- 

Re: Question about üarent-frame changes

[Ship Mints]

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

Daniel Mendler's corfu at-point completion package works on tty with child
frames, as an example to take a look at.

On Wed, Sep 18, 2024 at 10:27 AM Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Wed, 18 Sep 2024 16:15:56 +0200, martin rudalics <rudalics@gmx.at>
> said:
>
>     >> AFAICT from the Elisp Info docs, one is currently free to change the
>     >> parent-frame as one sees fit. That is, one can make a child a root
>     >> frame, a root frame a child, or change the parent of a child to
> another
>     >> root.
>     >>
>     >> I'm currently inclined to disallow parent-frame changes on ttys
>     >> entirely, unless it is used for something. Couldn't find something
>     >> today, but maybe something is a package outside Emacs' repo, or I'm
> just
>     >> ont looking for the right thing.
>
>     martin> I'm not aware of people using multiple frames on TTYs and I
> have no idea
>     martin> whether child frames out there are even intended to be
> reparented.
>
> I do it all the time. But obviously they each occupy the full
> terminal.
>
>     martin> Reparenting is useful because you can set up one child frame
> for some
>     martin> special purpose, make it invisible when you don't need it, and
> move it
>     martin> to another frame and make it visible there whenever you want
> to.  On
>     martin> GUIs, this approach has the advantage that you can avoid the
> (at least
>     martin> here) costly process of setting up frame faces every time
> anew.  Emacs
>     martin> tooltips do that by default and I recall that showing a
> tooltip every
>     martin> time incurred two entire GC cycles here.
>
> Would setting up frame faces be that expensive on tty? Iʼd really love
> to have tty child frames, even if they were not blazingly fast.
>
> In any case, I took a quick look at "posframe", it doesnʼt do any
> reparenting that I can see.
>
> Robert
> --
>
>

[-- Attachment #2: Type: text/html, Size: 2567 bytes --]

Re: Question about üarent-frame changes

[Gerd Möllmann]

Ship Mints <shipmints@gmail.com> writes:

> Daniel Mendler's corfu at-point completion package works on tty with
> child frames, as an example to take a look at.

Do you mean corfu-terminal? That's a clever workaround for the
non-existence of child frames on ttys using overlays and display
properties IIRC. It can't really replace child frames, though.

Re: Question about üarent-frame changes

[Ship Mints]

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

Yes, sorry, corfu-terminal when in tty mode.

On Wed, Sep 18, 2024 at 11:26 AM Gerd Möllmann <gerd.moellmann@gmail.com>
wrote:

> Ship Mints <shipmints@gmail.com> writes:
>
> > Daniel Mendler's corfu at-point completion package works on tty with
> > child frames, as an example to take a look at.
>
> Do you mean corfu-terminal? That's a clever workaround for the
> non-existence of child frames on ttys using overlays and display
> properties IIRC. It can't really replace child frames, though.
>

[-- Attachment #2: Type: text/html, Size: 953 bytes --]

Re: Question about üarent-frame changes

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>     martin> Reparenting is useful because you can set up one child frame for some
>     martin> special purpose, make it invisible when you don't need it, and move it
>     martin> to another frame and make it visible there whenever you want to.  On
>     martin> GUIs, this approach has the advantage that you can avoid the (at least
>     martin> here) costly process of setting up frame faces every time anew.  Emacs
>     martin> tooltips do that by default and I recall that showing a tooltip every
>     martin> time incurred two entire GC cycles here.
>
> Would setting up frame faces be that expensive on tty? Iʼd really love
> to have tty child frames, even if they were not blazingly fast.

From what I've seen so far, it's pretty fast, but OTOH my machine is
pretty fast (M1 pro). Let's see how it does when I'm a bit further. At
least hiding frames on ttys should be there before I can really try it
with posframe. Maybe also moving/resizing also.

> In any case, I took a quick look at "posframe", it doesnʼt do any
> reparenting that I can see.

Thanks! Corfu doesn't re-parent either, AFAICT. That are the two I care
about :-).

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

> Robert Pluim <rpluim@gmail.com> writes:
>
>>     martin> Reparenting is useful because you can set up one child frame for some
>>     martin> special purpose, make it invisible when you don't need it, and move it
>>     martin> to another frame and make it visible there whenever you want to.  On
>>     martin> GUIs, this approach has the advantage that you can avoid the (at least
>>     martin> here) costly process of setting up frame faces every time anew.  Emacs
>>     martin> tooltips do that by default and I recall that showing a tooltip every
>>     martin> time incurred two entire GC cycles here.
>>
>> Would setting up frame faces be that expensive on tty? Iʼd really love
>> to have tty child frames, even if they were not blazingly fast.
>
>> From what I've seen so far, it's pretty fast, but OTOH my machine is
> pretty fast (M1 pro). Let's see how it does when I'm a bit further. At
> least hiding frames on ttys should be there before I can really try it
> with posframe. Maybe also moving/resizing also.

I think I can say now that it will probably be faster than on GUI, at
least on macOS. Running

  (defun my-make-child ()
    (interactive)
    (make-frame `((parent-frame . ,(selected-frame))
                  (background-color . "gray10")
                  (foreground-color . "white")
                  (top . 15)
                  (left . 40)
                  (width . 80)
                  (height . 25))))

  (defun my-time-child ()
    (interactive)
    (dotimes (i 500)
      (let ((f (my-make-child)))
        (sit-for 0)
        (delete-frame f))))

  (benchmark-run 1 (my-time-child))

shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
(for the KKP keyboard support, not for performance).

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Robert Pluim <rpluim@gmail.com> writes:
>>
>>>     martin> Reparenting is useful because you can set up one child frame for some
>>>     martin> special purpose, make it invisible when you don't need it, and move it
>>>     martin> to another frame and make it visible there whenever you want to.  On
>>>     martin> GUIs, this approach has the advantage that you can avoid the (at least
>>>     martin> here) costly process of setting up frame faces every time anew.  Emacs
>>>     martin> tooltips do that by default and I recall that showing a tooltip every
>>>     martin> time incurred two entire GC cycles here.
>>>
>>> Would setting up frame faces be that expensive on tty? Iʼd really love
>>> to have tty child frames, even if they were not blazingly fast.
>>
>>> From what I've seen so far, it's pretty fast, but OTOH my machine is
>> pretty fast (M1 pro). Let's see how it does when I'm a bit further. At
>> least hiding frames on ttys should be there before I can really try it
>> with posframe. Maybe also moving/resizing also.
>
> I think I can say now that it will probably be faster than on GUI, at
> least on macOS. Running
>
>   (defun my-make-child ()
>     (interactive)
>     (make-frame `((parent-frame . ,(selected-frame))
>                   (background-color . "gray10")
>                   (foreground-color . "white")
>                   (top . 15)
>                   (left . 40)
>                   (width . 80)
>                   (height . 25))))
>
>   (defun my-time-child ()
>     (interactive)
>     (dotimes (i 500)
>       (let ((f (my-make-child)))
>         (sit-for 0)
>         (delete-frame f))))
>
>   (benchmark-run 1 (my-time-child))
>
> shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
> (for the KKP keyboard support, not for performance).

Small correction - I had timed tty build with debug. It's actually 2s
instead of 8s.

Re: Question about üarent-frame changes

[martin rudalics]

 > Small correction - I had timed tty build with debug. It's actually 2s
 > instead of 8s.

How many GC cycles on GUI vs TTY?

martin

Re: Question about üarent-frame changes

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> Small correction - I had timed tty build with debug. It's actually 2s
>> instead of 8s.
>
> How many GC cycles on GUI vs TTY?

Sorry, don't know. It's all with MPS.

Re: Question about üarent-frame changes

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>,  Emacs Devel <emacs-devel@gnu.org>
> Date: Wed, 25 Sep 2024 13:13:09 +0200
> 
> > shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
> > (for the KKP keyboard support, not for performance).
> 
> Small correction - I had timed tty build with debug. It's actually 2s
> instead of 8s.

Thanks.  It would be interesting to know which part takes
significantly more time on GUI terminals wrt TTYs.  A tenfold
performance difference should be easy to explain, I hope.

Re: Question about üarent-frame changes

[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 <emacs-devel@gnu.org>
>> Date: Wed, 25 Sep 2024 13:13:09 +0200
>>
>> > shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
>> > (for the KKP keyboard support, not for performance).
>>
>> Small correction - I had timed tty build with debug. It's actually 2s
>> instead of 8s.
>
> Thanks.  It would be interesting to know which part takes
> significantly more time on GUI terminals wrt TTYs.  A tenfold
> performance difference should be easy to explain, I hope.

I don't seem to get profiling to work on macOS 15 + Xcode 16 at the moment.

Maybe someone else could run the benchmark I posted under perf? It
should just work with an existing master, or 30, or 29 on GUIs.

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: martin rudalics <rudalics@gmx.at>,  Emacs Devel <emacs-devel@gnu.org>
>>> Date: Wed, 25 Sep 2024 13:13:09 +0200
>>>
>>> > shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
>>> > (for the KKP keyboard support, not for performance).
>>>
>>> Small correction - I had timed tty build with debug. It's actually 2s
>>> instead of 8s.
>>
>> Thanks.  It would be interesting to know which part takes
>> significantly more time on GUI terminals wrt TTYs.  A tenfold
>> performance difference should be easy to explain, I hope.
>
> I don't seem to get profiling to work on macOS 15 + Xcode 16 at the moment.
>
> Maybe someone else could run the benchmark I posted under perf? It
> should just work with an existing master, or 30, or 29 on GUIs.

Got at least something out of Instruments today. An example run in a
debug build with MPS shows as "Heaviest Stack Trace" this:

21.15 s  94,1 %	0 s	  Main Thread  0x158f26
18.63 s  82,9 %	0 s	                                          apply_lambda
12.11 s  53,9 %	0 s	                                           exec_byte_code
8.04 s  35,8 %	1.00 ms	                                                             CA::Context::commit_transaction(CA::Transaction*, double, double*)
5.33 s  23,7 %	0 s	                                                              CA::Layer::layout_if_needed(CA::Transaction*)
5.32 s  23,7 %	2.00 ms	                                                                redisplay_internal
3.96 s  17,6 %	0 s	                                                                 redisplay_windows
3.56 s  15,8 %	0 s	                                                                     update_frame_tool_bar_1
2.62 s  11,6 %	0 s	                                                                      -[NSToolbar _setConfigurationFromDictionary:notifyFamilyAndUpdateDefaults:upgradedConfiguration:]
1.81 s   8,1 %	0 s	                                                                                    -[NSToolbarView _layoutDirtyItemViewersAndTileToolbar]
854.00 ms   3,8 %	0 s	                                                                                     -[NSToolbarView _configureItemViewersForLayoutIfNecessary]
669.00 ms   3,0 %	0 s	                                                                                       -[NSToolbarItemViewer _configureViewerSize]
397.00 ms   1,8 %	0 s	                                                                                        -[NSToolbarItem _scalableMinSize]
359.00 ms   1,6 %	0 s	                                                                                          -[NSToolbarItem _itemViewMinSize:maxSize:stretchesContent:]
179.00 ms   0,8 %	0 s	                                                                                           _nsis_frameInEngine

I think this this means that the window system itself takes a lot of the
time (CA::..., NS...), plus redisplay on GUI of course, which I would
expect to be a bit slower than on ttys, but mainly the window system.

That's also consistent with the fact that the times differ only a bit
between optimized and debug builds with checking=all.

Not much one can do about that, I guess. At least on macOS, it could
be different on other platforms of course.

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>>> Cc: martin rudalics <rudalics@gmx.at>,  Emacs Devel <emacs-devel@gnu.org>
>>>> Date: Wed, 25 Sep 2024 13:13:09 +0200
>>>>
>>>> > shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
>>>> > (for the KKP keyboard support, not for performance).
>>>>
>>>> Small correction - I had timed tty build with debug. It's actually 2s
>>>> instead of 8s.
>>>
>>> Thanks.  It would be interesting to know which part takes
>>> significantly more time on GUI terminals wrt TTYs.  A tenfold
>>> performance difference should be easy to explain, I hope.
>>
>> I don't seem to get profiling to work on macOS 15 + Xcode 16 at the moment.
>>
>> Maybe someone else could run the benchmark I posted under perf? It
>> should just work with an existing master, or 30, or 29 on GUIs.
>
> Got at least something out of Instruments today. An example run in a
> debug build with MPS shows as "Heaviest Stack Trace" this:
>
> 21.15 s  94,1 %	0 s	  Main Thread  0x158f26
> 18.63 s  82,9 %	0 s	                                          apply_lambda
> 12.11 s  53,9 %	0 s	                                           exec_byte_code
> 8.04 s 35,8 % 1.00 ms
> CA::Context::commit_transaction(CA::Transaction*, double, double*)
> 5.33 s 23,7 % 0 s CA::Layer::layout_if_needed(CA::Transaction*)
> 5.32 s  23,7 %	2.00 ms	                                                                redisplay_internal
> 3.96 s  17,6 %	0 s	                                                                 redisplay_windows
> 3.56 s 15,8 % 0 s update_frame_tool_bar_1
> 2.62 s 11,6 % 0 s -[NSToolbar
> _setConfigurationFromDictionary:notifyFamilyAndUpdateDefaults:upgradedConfiguration:]
> 1.81 s  8,1 % 0 s -[NSToolbarView
> _layoutDirtyItemViewersAndTileToolbar]
> 854.00 ms  3,8 % 0 s -[NSToolbarView
> _configureItemViewersForLayoutIfNecessary]
> 669.00 ms  3,0 % 0 s -[NSToolbarItemViewer _configureViewerSize]
> 397.00 ms  1,8 % 0 s -[NSToolbarItem _scalableMinSize]
> 359.00 ms  1,6 % 0 s -[NSToolbarItem
> _itemViewMinSize:maxSize:stretchesContent:]
> 179.00 ms  0,8 % 0 s _nsis_frameInEngine
>
> I think this this means that the window system itself takes a lot of the
> time (CA::..., NS...), plus redisplay on GUI of course, which I would
> expect to be a bit slower than on ttys, but mainly the window system.
>
> That's also consistent with the fact that the times differ only a bit
> between optimized and debug builds with checking=all.
>
> Not much one can do about that, I guess. At least on macOS, it could
> be different on other platforms of course.

Maybe I should add that I don't think this is a problem. It's more than
fast enough for me at least, with ca. 50ms for a make-frame + redisplay
+ delete-frame.

Re: Question about üarent-frame changes

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rpluim@gmail.com,  rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Thu, 26 Sep 2024 07:01:16 +0200
> 
> 
> Maybe I should add that I don't think this is a problem. It's more than
> fast enough for me at least, with ca. 50ms for a make-frame + redisplay
> + delete-frame.

Yes, 50 ms is below the threshold for most of us.  But the question is
what happens on slower systems.

Re: Question about üarent-frame changes

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rpluim@gmail.com,  rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Thu, 26 Sep 2024 06:54:44 +0200
> 
> I think this this means that the window system itself takes a lot of the
> time (CA::..., NS...), plus redisplay on GUI of course, which I would
> expect to be a bit slower than on ttys, but mainly the window system.
> 
> That's also consistent with the fact that the times differ only a bit
> between optimized and debug builds with checking=all.
> 
> Not much one can do about that, I guess. At least on macOS, it could
> be different on other platforms of course.

Thanks.

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Robert Pluim <rpluim@gmail.com> writes:
>>>
>>>>     martin> Reparenting is useful because you can set up one child frame for some
>>>>     martin> special purpose, make it invisible when you don't need it, and move it
>>>>     martin> to another frame and make it visible there whenever you want to.  On
>>>>     martin> GUIs, this approach has the advantage that you can avoid the (at least
>>>>     martin> here) costly process of setting up frame faces every time anew.  Emacs
>>>>     martin> tooltips do that by default and I recall that showing a tooltip every
>>>>     martin> time incurred two entire GC cycles here.
>>>>
>>>> Would setting up frame faces be that expensive on tty? Iʼd really love
>>>> to have tty child frames, even if they were not blazingly fast.
>>>
>>>> From what I've seen so far, it's pretty fast, but OTOH my machine is
>>> pretty fast (M1 pro). Let's see how it does when I'm a bit further. At
>>> least hiding frames on ttys should be there before I can really try it
>>> with posframe. Maybe also moving/resizing also.
>>
>> I think I can say now that it will probably be faster than on GUI, at
>> least on macOS. Running
>>
>>   (defun my-make-child ()
>>     (interactive)
>>     (make-frame `((parent-frame . ,(selected-frame))
>>                   (background-color . "gray10")
>>                   (foreground-color . "white")
>>                   (top . 15)
>>                   (left . 40)
>>                   (width . 80)
>>                   (height . 25))))
>>
>>   (defun my-time-child ()
>>     (interactive)
>>     (dotimes (i 500)
>>       (let ((f (my-make-child)))
>>         (sit-for 0)
>>         (delete-frame f))))
>>
>>   (benchmark-run 1 (my-time-child))
>>
>> shows 24s with GUI, and 8s on tty. I'm using Alacritty, in case that matters
>> (for the KKP keyboard support, not for performance).
>
> Small correction - I had timed tty build with debug. It's actually 2s
> instead of 8s.

I think I have hiding/showing child frames now. Timing this:

  (defun my-time-hide ()
    (interactive)
      (let ((f (my-make-child)))
        (dotimes (i 500)
          (make-frame-invisible f)
          (sit-for 0)
          (make-frame-visible f)
          (sit-for 0))))

gives 0.3s on ttys, and 8.5s with Cocoa. Not too shabby :-).

Also note that it's ca, 3 times faster on Cocoa than deleting and
recreating the child frame is. That's ca. 17ms. And it's I think what
Corfu and Posframe do (not 100% sure about Posframe).

Re: Question about üarent-frame changes

[martin rudalics]

 > Would setting up frame faces be that expensive on tty?

It should be much cheaper than on a graphics display because there
are less faces and colors.

 > Iʼd really love
 > to have tty child frames, even if they were not blazingly fast.

The key point is to make switching their visibility status reasonably
fast.

martin

Re: Question about üarent-frame changes

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> AFAICT from the Elisp Info docs, one is currently free to change the
>> parent-frame as one sees fit. That is, one can make a child a root
>> frame, a root frame a child, or change the parent of a child to another
>> root.
>>
>> I'm currently inclined to disallow parent-frame changes on ttys
>> entirely, unless it is used for something. Couldn't find something
>> today, but maybe something is a package outside Emacs' repo, or I'm just
>> ont looking for the right thing.
>
> I'm not aware of people using multiple frames on TTYs and I have no idea
> whether child frames out there are even intended to be reparented.

Ok, thanks. I'm using mulitple frames sometimes, but in the end seem to
99% end up using tabs (C-x t 2 etc), like on GUI.

> Reparenting is useful because you can set up one child frame for some
> special purpose, make it invisible when you don't need it, and move it
> to another frame and make it visible there whenever you want to.  On
> GUIs, this approach has the advantage that you can avoid the (at least
> here) costly process of setting up frame faces every time anew.  

Hm, that might indeed be an interesting optimization.

> Emacs tooltips do that by default and I recall that showing a tooltip
> every time incurred two entire GC cycles here.

(Oh, hadn't thought of tooltips on ttys yet. New entry in my list :-).)

So I guess I'll keep at least the option of re-parenting child frames to
another root frame open, until I know more about how fast that all
turns out to be. If I had to guess, face realization on ttys could well
be faster than on GUIs because all the font stuff doesn't have to be
done.

But I'll disable to root <-> child transformation. That feels abit
esoteric.

Thanks!

Re: Question about üarent-frame changes

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Date: Wed, 18 Sep 2024 17:03:34 +0200
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> > Emacs tooltips do that by default and I recall that showing a tooltip
> > every time incurred two entire GC cycles here.
> 
> (Oh, hadn't thought of tooltips on ttys yet. New entry in my list :-).)

Tooltips on ttys are shown in the echo-area.

Re: Question about üarent-frame changes

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> Date: Wed, 18 Sep 2024 17:03:34 +0200
>> 
>> martin rudalics <rudalics@gmx.at> writes:
>> 
>> > Emacs tooltips do that by default and I recall that showing a tooltip
>> > every time incurred two entire GC cycles here.
>> 
>> (Oh, hadn't thought of tooltips on ttys yet. New entry in my list :-).)
>
> Tooltips on ttys are shown in the echo-area.

Yes, because I didn't have child frames back then :-).

Re: Question about üarent-frame changes

[Eli Zaretskii]

> Date: Wed, 18 Sep 2024 16:15:56 +0200
> Cc: Emacs Devel <emacs-devel@gnu.org>
> From: martin rudalics <rudalics@gmx.at>
> 
> I'm not aware of people using multiple frames on TTYs and I have no idea
> whether child frames out there are even intended to be reparented.
> 
> Reparenting is useful because you can set up one child frame for some
> special purpose, make it invisible when you don't need it, and move it
> to another frame and make it visible there whenever you want to.  On
> GUIs, this approach has the advantage that you can avoid the (at least
> here) costly process of setting up frame faces every time anew.  Emacs
> tooltips do that by default and I recall that showing a tooltip every
> time incurred two entire GC cycles here.

What you describe makes sens for GUI frames, but seems to make little
sense for TTY frames, because frame visibility situation there is much
simpler.

Re: Question about üarent-frame changes

[martin rudalics]

 > What you describe makes sens for GUI frames, but seems to make little
 > sense for TTY frames, because frame visibility situation there is much
 > simpler.

You mean because only one normal frame can be visible at any time.
However, child frames complicate the situation considerably because
Emacs itself has to take care of their visibility instead of the WM.

For example, I can type into a GUI window text beneath a (small) child
frame as long as that child frame doesn't have focus.  Emulating such
behavior with text emanating at the right of the child frame on a TTY
seems tricky at least.

martin

Re: Question about üarent-frame changes

[Po Lu]

martin rudalics <rudalics@gmx.at> writes:

>> What you describe makes sens for GUI frames, but seems to make little
>> sense for TTY frames, because frame visibility situation there is much
>> simpler.
>
> You mean because only one normal frame can be visible at any time.
> However, child frames complicate the situation considerably because
> Emacs itself has to take care of their visibility instead of the WM.
>
> For example, I can type into a GUI window text beneath a (small) child
> frame as long as that child frame doesn't have focus.  Emulating such
> behavior with text emanating at the right of the child frame on a TTY
> seems tricky at least.
>
> martin

Most of the extant popup packages that exercise child frames also retain
and reparent them across different parents, and as such, Gerd will need
to implement reparenting.

Re: Question about üarent-frame changes

[martin rudalics]

Are there any?> Most of the extant popup packages that exercise child frames also retain
 > and reparent them across different parents,

What do the less extant packages do instead?  Do they exist at all?

 > and as such, Gerd will need
 > to implement reparenting.

Or emulate it in some way.

martin

Re: Question about üarent-frame changes

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> What you describe makes sens for GUI frames, but seems to make little
>> sense for TTY frames, because frame visibility situation there is much
>> simpler.
>
> You mean because only one normal frame can be visible at any time.
> However, child frames complicate the situation considerably because
> Emacs itself has to take care of their visibility instead of the WM.

Yes, that's true but I think I have that, at least in principle.

The biggest problem for me in this area today is that "visibility" on
GUIs and ttys apparently is not the same thing. For example,
make-frame-visible seems to do nothing for tty frames. So I guess all
tty frames are always visible in the sense that frame::visible is
non-zero.

But that would be too easy of course, which is why frame::visible has 2
bits, and if the second bit is set the frame is "obscured" (happens with
C-x 5 2), which I'd call sort of invisible because it can't be seen but
that's of course naive.

Grumpy.

Re: Question about üarent-frame changes

[martin rudalics]

 > The biggest problem for me in this area today is that "visibility" on
 > GUIs and ttys apparently is not the same thing. For example,
 > make-frame-visible seems to do nothing for tty frames. So I guess all
 > tty frames are always visible in the sense that frame::visible is
 > non-zero.

You mean because 'suspend-tty' acts on top-level frames only?

Another issue we would have to resolve in some way is whether a child
frame should (or could) be given input focus on TTYs: That is, whether a
user may type "into" a child frame, for example, when an application
issues a 'yes-or-no-p' question within a child frame equipped with a
minibuffer window.

 > But that would be too easy of course, which is why frame::visible has 2
 > bits, and if the second bit is set the frame is "obscured" (happens with
 > C-x 5 2), which I'd call sort of invisible because it can't be seen but
 > that's of course naive.

Wasn't that second bit used exclusively for redisplay purposes and as
such not available to Lisp code?

martin

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

martin rudalics <rudalics@gmx.at> writes:

>> The biggest problem for me in this area today is that "visibility" on
>> GUIs and ttys apparently is not the same thing. For example,
>> make-frame-visible seems to do nothing for tty frames. So I guess all
>> tty frames are always visible in the sense that frame::visible is
>> non-zero.
>
> You mean because 'suspend-tty' acts on top-level frames only?

Haven't looked at suspend-tty yet. The list grows and grows :-).

No, the problem is that the whole hide/show frames is not implemented on
ttys presently. But I think I need that to work as it does on GUIs to be
compatible with existing packages like Corfu, which uses that.

Which means I have to implement hide/show on ttys like it is on GUIS,
amd handle the "obscured" case differently. Not sure sure if it needs a
bit in the frame at all, FWIW, since we know the topmost frame root
frame on a tty anyway, which is the only one that is visible. Anyway.
Doesn't look like a lot of fun :-).

> Another issue we would have to resolve in some way is whether a child
> frame should (or could) be given input focus on TTYs: That is, whether a
> user may type "into" a child frame, for example, when an application
> issues a 'yes-or-no-p' question within a child frame equipped with a
> minibuffer window.

My aim is to let tty child frames act like their GUI counterpart as far
as possible, which seems to mean that child frames act like any other
frame for the most part.

And that's the case currently with what I have so far. Opening a child
frame is like C-x 5 2, only that the child is displayed on top of its
parent and so on. The child can have a minibuffer and everything else.
(Except for the menu bar thing we talked about, I deliberately turned
that off).

In the y-or-n-p case, this looks like this


[-- Attachment #2: Screenshot 2024-09-19 at 11.05.56.png --]
[-- Type: image/png, Size: 445852 bytes --]

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


That is with

(defun emacs-user:my-make-child ()
  (interactive)
  (make-frame `((parent-frame . ,(selected-frame))
		(background-color . "gray10")
		(foreground-color . "white")
		(top . 15)
		(left . 40)
		(width . 80)
		(height . 25))))

So it's a "normal" frame. Haven't gotten to minibuffer-only frames and
what else is possible. (TIL there is also a delete-after or so frame
parameter). There is probably something lurking there as well.

>> But that would be too easy of course, which is why frame::visible has 2
>> bits, and if the second bit is set the frame is "obscured" (happens with
>> C-x 5 2), which I'd call sort of invisible because it can't be seen but
>> that's of course naive.
>
> Wasn't that second bit used exclusively for redisplay purposes and as
> such not available to Lisp code?

That's true, but the whole rest of hiding/showing frames isn't there on
ttys.

Re: Question about üarent-frame changes

[martin rudalics]

 > In the y-or-n-p case, this looks like this

Looks good.  But where does the user's answer appear?  In the
child-frame's minibuffer window?

martin

Re: Question about üarent-frame changes

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> In the y-or-n-p case, this looks like this
>
> Looks good.  But where does the user's answer appear?  In the
> child-frame's minibuffer window?

If you mean the 'y' when I type y at the prompt, that appears just after
the prompt, that should be the echo area I think.

(Sorry couldn't make a screen capture of that because I either can't type
anything into Emacs when Screen Capture runs, or the echo area is
cleared when I start Screen Capture.)

Re: Question about üarent-frame changes

[martin rudalics]

 >> Looks good.  But where does the user's answer appear?  In the
 >> child-frame's minibuffer window?
 >
 > If you mean the 'y' when I type y at the prompt, that appears just after
 > the prompt, that should be the echo area I think.

Good.  I asked because I didn't see the cursor in the minibuffer window.
But screenshots often don't capture cursors.

martin

Re: Question about üarent-frame changes

[Gerd Möllmann]

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

martin rudalics <rudalics@gmx.at> writes:

>>> Looks good.  But where does the user's answer appear?  In the
>>> child-frame's minibuffer window?
>>
>> If you mean the 'y' when I type y at the prompt, that appears just after
>> the prompt, that should be the echo area I think.
>
> Good.  I asked because I didn't see the cursor in the minibuffer window.
> But screenshots often don't capture cursors.

Ah, okay, that's something special with y-or-n-p. Here's something from
M-x where one can see the use of the minibuffer of the child frame:


[-- Attachment #2: Screenshot 2024-09-19 at 14.45.08.png --]
[-- Type: image/png, Size: 257075 bytes --]

Re: Question about üarent-frame changes

[Eli Zaretskii]

> Date: Wed, 18 Sep 2024 20:52:00 +0200
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > What you describe makes sens for GUI frames, but seems to make little
>  > sense for TTY frames, because frame visibility situation there is much
>  > simpler.
> 
> You mean because only one normal frame can be visible at any time.
> However, child frames complicate the situation considerably because
> Emacs itself has to take care of their visibility instead of the WM.
> 
> For example, I can type into a GUI window text beneath a (small) child
> frame as long as that child frame doesn't have focus.  Emulating such
> behavior with text emanating at the right of the child frame on a TTY
> seems tricky at least.

I'm saying that this scenario which you described:

> Reparenting is useful because you can set up one child frame for some
> special purpose, make it invisible when you don't need it, and move it
> to another frame and make it visible there whenever you want to.  On
> GUIs, this approach has the advantage that you can avoid the (at least
> here) costly process of setting up frame faces every time anew.  Emacs
> tooltips do that by default and I recall that showing a tooltip every
> time incurred two entire GC cycles here.

sounds not very useful to me on a TTY, because switching frames on a
TTY will make the child frame invisible anyway.  And why would I want
to see a child of frame F1 when I display only frame F2?

So reparenting seems almost pointless on a TTY.

Of course, I'm not objected to allowing such reparenting on TTY
displays, but given that Gerd says it's not trivial, I think we will
be fine without that feature on TTY displays.

Re: Question about üarent-frame changes

[martin rudalics]

 > I'm saying that this scenario which you described:
 >
 >> Reparenting is useful because you can set up one child frame for some
 >> special purpose, make it invisible when you don't need it, and move it
 >> to another frame and make it visible there whenever you want to.  On
 >> GUIs, this approach has the advantage that you can avoid the (at least
 >> here) costly process of setting up frame faces every time anew.  Emacs
 >> tooltips do that by default and I recall that showing a tooltip every
 >> time incurred two entire GC cycles here.
 >
 > sounds not very useful to me on a TTY, because switching frames on a
 > TTY will make the child frame invisible anyway.  And why would I want
 > to see a child of frame F1 when I display only frame F2?

Because the calling code may reparent the child frame from F1 to F2
whenever the user switches from frame F1 to frame F2.  At least Po Lu
said that applications do such reparenting.

 > So reparenting seems almost pointless on a TTY.

If the application asks for it, we'd have to decide what to do.  Clone
the child frame in some way, for example, so that while there are two
physical child frames - one for F1 and one for F2 - the application sees
only one.

martin

Re: Question about üarent-frame changes

[Eli Zaretskii]

> Date: Thu, 19 Sep 2024 10:10:11 +0200
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > sounds not very useful to me on a TTY, because switching frames on a
>  > TTY will make the child frame invisible anyway.  And why would I want
>  > to see a child of frame F1 when I display only frame F2?
> 
> Because the calling code may reparent the child frame from F1 to F2
> whenever the user switches from frame F1 to frame F2.  At least Po Lu
> said that applications do such reparenting.

Isn't that the same as simply showing the child frame even though its
parent frame is obscured?

And I'd need to hear more details about what the application wants to
achieve by such reparenting, to understand the issue.

>  > So reparenting seems almost pointless on a TTY.
> 
> If the application asks for it, we'd have to decide what to do.  Clone
> the child frame in some way, for example, so that while there are two
> physical child frames - one for F1 and one for F2 - the application sees
> only one.

What do those applications do now on TTY displays, when child frames
are not available at all?  We should keep the current situation in
mind when assessing the potential damage of not supporting
reparenting.  Assessing that from the POV of what is available on GUI
displays skews the perspective.

And once again: if implementing reparenting is not hard, I'm not
objected to having it.  All I'm saying is that it sounds like not
having that on TTYs will not be a huge loss, and the feature will be
useful enough even without that -- if implementing that is hard.

Re: Question about üarent-frame changes

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 19 Sep 2024 10:10:11 +0200
>> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>> 
>>  > sounds not very useful to me on a TTY, because switching frames on a
>>  > TTY will make the child frame invisible anyway.  And why would I want
>>  > to see a child of frame F1 when I display only frame F2?
>> 
>> Because the calling code may reparent the child frame from F1 to F2
>> whenever the user switches from frame F1 to frame F2.  At least Po Lu
>> said that applications do such reparenting.
>
> Isn't that the same as simply showing the child frame even though its
> parent frame is obscured?
>
> And I'd need to hear more details about what the application wants to
> achieve by such reparenting, to understand the issue.

They simply wish to retain created child frames for as long a period as
possible, because frame creation is expensive, and configuring a child
frame to behave as intended is hard work.  See posframe.el (on ELPA) for
a typical instance, where three years ago I encountered the same dilemma
with the Haiku port.

Re: Question about üarent-frame changes

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: martin rudalics <rudalics@gmx.at>,  gerd.moellmann@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 19 Sep 2024 16:41:24 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Thu, 19 Sep 2024 10:10:11 +0200
> >> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> >> From: martin rudalics <rudalics@gmx.at>
> >> 
> >>  > sounds not very useful to me on a TTY, because switching frames on a
> >>  > TTY will make the child frame invisible anyway.  And why would I want
> >>  > to see a child of frame F1 when I display only frame F2?
> >> 
> >> Because the calling code may reparent the child frame from F1 to F2
> >> whenever the user switches from frame F1 to frame F2.  At least Po Lu
> >> said that applications do such reparenting.
> >
> > Isn't that the same as simply showing the child frame even though its
> > parent frame is obscured?
> >
> > And I'd need to hear more details about what the application wants to
> > achieve by such reparenting, to understand the issue.
> 
> They simply wish to retain created child frames for as long a period as
> possible, because frame creation is expensive, and configuring a child
> frame to behave as intended is hard work.  See posframe.el (on ELPA) for
> a typical instance, where three years ago I encountered the same dilemma
> with the Haiku port.

In what sense is creating and configuring a frame "expensive" and
"hard"?  Given that we have current-window-configuration and
set-window-configuration, I wouldn't expect it to be hard.

Re: Question about üarent-frame changes

[martin rudalics]

 > In what sense is creating and configuring a frame "expensive" and
 > "hard"?  Given that we have current-window-configuration and
 > set-window-configuration, I wouldn't expect it to be hard.

Neither of these are of any use for new frames.

martin

Re: Question about üarent-frame changes

[Eli Zaretskii]

> Date: Thu, 19 Sep 2024 13:13:21 +0200
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > In what sense is creating and configuring a frame "expensive" and
>  > "hard"?  Given that we have current-window-configuration and
>  > set-window-configuration, I wouldn't expect it to be hard.
> 
> Neither of these are of any use for new frames.

Too bad.  But we still have frameset.el.

Re: Question about üarent-frame changes

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

> If the application asks for it, we'd have to decide what to do.  Clone
> the child frame in some way, for example, so that while there are two
> physical child frames - one for F1 and one for F2 - the application sees
> only one.

Cloning won't be necessary, that's a thing I can say with certainty.
With what I have done today, reparenting a child will be allowed, but
not making a child a root or the other way 'round, for reasons of
laziness if you will.

And I got a redisplay problem when popping up a backtrace buffer on a
child frame for some reason. Hm, new list entry.

Re: Question about üarent-frame changes

[Po Lu]

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

> Cloning won't be necessary, that's a thing I can say with certainty.
> With what I have done today, reparenting a child will be allowed, but
> not making a child a root or the other way 'round, for reasons of
> laziness if you will.

This is alright, for it is already more or less true of the popular GUI
builds, and for reasons beyond our control.