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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: 51883 <at> debbugs.gnu.org
Cc: michael_heerdegen <at> web.de, eliz <at> gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: bug#51883: 29.0.50; Command to get accidentally deleted frames back
Date: Sat, 22 Jan 2022 20:08:12 +0200

> But as for loading the package, the problem is more general in the sense
> that maybe we should refrain from loading the package just because
> a frame is deleted.
>
> So maybe we should change the code so the hook's function doesn't
> require loading `frameset.el`.  AFAICT fundamentally, the only function
> from `frameset.el` that it needs is `frameset-filter-params`, so maybe
> we should move some of that code to `frame.el`.
>
> To make up for it, maybe we can move some of the `undelete-frame` code
> to `frameset.el` since it can't be used without `frameset.el` anyway?
>
>>   . saving configurations of 16 deleted frames _by_default_ means we
>>     again impose on all users something that only some of them will use
>
> 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?  For example,
`clone-frame` doesn't use framesets, and the effect of `clone-frame`
should be the same as what `undelete-frame` does.  The difference
between them is that with `clone-frame` the original frame is not deleted.

Previous Next

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