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: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: michael_heerdegen <at> web.de, 51883 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#51883: 29.0.50; Command to get accidentally deleted frames back
Date: Fri, 19 Nov 2021 14:17:24 +0200

> Date: Fri, 19 Nov 2021 09:00:39 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 51883 <at> debbugs.gnu.org, juri <at> linkov.net, michael_heerdegen <at> web.de
> 
> > Usually, commands that use both numeric and raw prefix arg do something 
> > very different with the raw argument, which is not the case here.
> 
> The last version of the patch now does that, too: no argument and a raw 
> argument means "most recent", a numeric argument means "Nth".

That's not "very different" in my book.  So I think only numeric
arguments should do that, with 1 being the default and meaning the
most-recently deleted one.  Yes, we will lose one frame this way, but
I don't think it's important enough to justify such strange usage of
the prefix arg.

> > I'd prefer to make it opt-in.  I see no reason to force on everyone a 
> > new feature that doesn't sound like it's urgent or important enough to 
> > justify the behavior change.  Even though the memory it uses is not 
> > large, it's still memory, and it still increases consing each time a 
> > frame is deleted.  For example, some people turn on all kinds of 
> > optional features that pop up new frames in many situations, and who 
> > knows what this will cause in those usage patterns.  Why risk such 
> > unintended consequences on behalf of a minor feature?
> 
> I hear your arguments, but IMO that would be like making "undo" opt-in. 
> I also wouldn't call that a "minor" feature, it's worth an entry in the 
> File menu.  Indeed we don't know what this could cause with exotic usage 
> patterns, so I suggest, given that the release of Emacs 29 is far away in 
> the future, to make it opt-out on the trunk, and if someone protests 
> because it breaks their usage pattern before Emacs 29 is released, to make 
> it opt-in instead.

No, please make it opt-in from the get-go, which will also remove the
need for some of the code which messes with the initial frame.  If
many users will request it be on by default, we will then reconsider.

Previous Next

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