GNU bug report logs - #51883
29.0.50; Command to get accidentally deleted frames back

Previous Next

Full log

Message #222 received at 51883 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 Gregory Heytings <gregory <at> heytings.org>, 51883 <at> debbugs.gnu.org
Subject: Re: bug#51883: 29.0.50; Command to get accidentally deleted frames
 back
Date: Sun, 23 Jan 2022 11:01:08 -0500

>>>> IIUC framesets are designed to be serializable so they shouldn't hold on
>>>> to external data like buffers and windows, so such 16 elements should
>>>> cost very little in terms of heap use.
>>> OTOH, since framesets are designed to be serializable, isn't it
>>> overkill to use framesets in the same session?
>> Not sure what you mean by "overkill".  AFAIK it makes them more lightweight.
> Without framesets it doesn't require loading frameset.el.

The alternative to framesets, AFAIK is to keep actual frames around,
which are more expansive than framesets.

Or what do you suggest we use instead?

>>> For example, `clone-frame` doesn't use framesets, and the effect of
>>> `clone-frame` should be the same as what `undelete-frame` does.
>> Except it actually creates a frame, so it requires a lot more resources.
> I don't understand: `clone-frame` creates a new frame with `make-frame`,
> and `undelete-frame` creates a new frame with `make-frame-on-display`.

I was confused.  I still haven't understood you correctly, but at
least now I'm aware of it.

I'm talking about the cost of the representation of the frames we
deleted until the moment we undelete them.  I can't see how
`clone-frame` helps in this respect.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.