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

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 20:12:22 +0200

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

I didn't mean to keep actual frames around.  I thought about keeping
only the same data that is used by `clone-frame` to make a new frame
identical to the original frame.  In case of `undelete-frame` this data
can be used to make a frame identical to the deleted frame.
I.e. a lightweight version of framesets, that avoids loading frameset.el.
This mostly means that after deleting the frame, only frame parameters
are kept from garbage collection, that later can be reused when making
a new frame on undeletion.

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

Then the question is what takes more memory: loading frameset.el,
or keeping frame parameters of the deleted frame?

Previous Next

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