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

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Mon, 15 Nov 2021 23:39:02 UTC

Severity: wishlist

Tags: patch

Fixed in version 29.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 51883 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#51883: 29.0.50; Command to get accidentally deleted frames
 back
Date: Tue, 25 Jan 2022 16:58:15 +0100
> Which other parameters would you suggest to remove (on master)?

It would be pretentious to answer that question.  The comment starting
at line 261 of frameset.el tells that

;; - `window-id', `outer-window-id', `parent-id': They are assigned
;;   automatically and cannot be set, so keeping them is harmless, but they
;;   add clutter.  `window-system' is similar: it's assigned at frame
;;   creation, and does not serve any useful purpose later.

so according to that comment, leaving 'parent-id' in the list should not
have caused any problems.  Thanks to Juri, we know better now.

For anyone who wants to peruse the parameters of an existing frame,
however, reading the ";; Filtering" comment in frameset.el should be an
indispensable prerequisite.  Juanma (and maybe others) have invested a
lot of work there - consider entries on 'frameset--text-pixel-height' or
'minibuffer'.  Disregarding that text when implementing a function that
pretends to clone a frame is just recklessness.

martin





This bug report was last modified 3 years and 172 days ago.

Previous Next


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