bug#51883: 29.0.50; Command to get accidentally deleted frames back

[Juri Linkov <juri@linkov.net>]

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