From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#51883: 29.0.50; Command to get accidentally deleted frames back Date: Sun, 23 Jan 2022 20:12:22 +0200 Organization: LINKOV.NET Message-ID: <86zgnms469.fsf@mail.linkov.net> References: <87czn1gfb1.fsf@web.de> <838rxo0zk7.fsf@gnu.org> <86lez73auf.fsf@mail.linkov.net> <86y236vlfm.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20887"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: michael_heerdegen@web.de, Gregory Heytings , 51883@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 23 19:27:06 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nBhZx-0005GG-H1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jan 2022 19:27:05 +0100 Original-Received: from localhost ([::1]:40252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBhZw-0000NZ-Je for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jan 2022 13:27:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBhXy-0007WV-Lk for bug-gnu-emacs@gnu.org; Sun, 23 Jan 2022 13:25:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48321) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nBhXy-0005cv-9e for bug-gnu-emacs@gnu.org; Sun, 23 Jan 2022 13:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nBhXy-0003zh-7G for bug-gnu-emacs@gnu.org; Sun, 23 Jan 2022 13:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jan 2022 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51883 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 51883-submit@debbugs.gnu.org id=B51883.164296229015310 (code B ref 51883); Sun, 23 Jan 2022 18:25:02 +0000 Original-Received: (at 51883) by debbugs.gnu.org; 23 Jan 2022 18:24:50 +0000 Original-Received: from localhost ([127.0.0.1]:41221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBhXl-0003yl-Oa for submit@debbugs.gnu.org; Sun, 23 Jan 2022 13:24:50 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:60875) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBhXh-0003yE-Jy for 51883@debbugs.gnu.org; Sun, 23 Jan 2022 13:24:45 -0500 Original-Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id B318AFF80D; Sun, 23 Jan 2022 18:24:37 +0000 (UTC) In-Reply-To: (Stefan Monnier's message of "Sun, 23 Jan 2022 11:01:08 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:224956 Archived-At: >>>>> 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?