>>> >> > I tried to use this, but undelete-frame-mode in the File menu
>>> >> > makes no sense: when you mistakenly deleted a frame, you want
>>> >> > to undelete it immediately, so you open the File menu, and
>>> >> > see the message "No way, you can't undelete the deleted frame,
>>> >> > because you were careless and not enabled a special mode".
>>> >> >
>>> >> > So the most useful case for this feature is to get the
>>> >> > accidentally deleted frame back, and it fails to do this.
>>> >> >
>>> >> > Instead, it allows undeleting 16 frames in a special mode.
>>> >> > Is there really a human that can delete 16 frames, and then
>>> >> > remember what was on the 16th frame back?
>>> >> >
>>> >> > Rereading this thread indicates that the only concern about
>>> >> > enabling this by default was the memory footprint for remembering
>>> >> > 16 frames.  OTOH, this feature is really useful for remembering
>>> >> > 1 frame.  So this is what should be enabled by default:
>>> >>
>>> >> It seems this is the right thing to do, so now pushed to master.
>>> >
>>> > I'm sorry, you cannot do that.  We discussed this at some length and
>>> > reached certain conclusions.  Then you come and in effect say those
>>> > considerations and discussions make no sense, and you know better?
>>> > Let's please respect our discussions and decisions more than that.
>>> > And if you want others to respect your opinions, please respect
>>> > theirs, even if you disagree.  The feature as installed allows you to
>>> > customize it to have that mode turned on by default, so you could
>>> > easily fix your problem by doing that.
>>> >
>>> > Specifically to your main argument: it is no different from deleting a
>>> > file: unless the user took steps to configure the system to allow
>>> > undeleting deleted files, deleted files are lost forever.  Moreover,
>>> > in the case of an Emacs frame, nothing of terrible importance is
>>> > actually lost: the buffers displayed in that frame are still there,
>>> > and restoring the deleted frame by hand shouldn't take more than a few
>>> > moments.
>>> >
>>> > So I reverted this changeset.  Please in the future don't make such
>>> > changes unilaterally.
>>>
>>> This is not true.  This is not a unilateral change.  I posted a patch,
>>> then waited for comments 3 days, and when no one commented this means
>>> that everyone agreed that it's a more reasonable change, then pushed to
>>> master.
>>
>> I guess 3 days is not enough, especially in this time of year.  My
>> rule of thumb is to wait at least a week, possibly two.
>>
>> But in any case, the amount of time you waited is not the main issue
>> here.  The main issue is that we decided to implement this the way we
>> did, and you were even part of that discussion.  It makes no sense to
>> undo all that because you suddenly don't like the results.
>
> After applying the patch to test whether it correctly restores the tab-bar,
> I discovered that the weirdest thing was added to the main menu.
>
> No other app has such unusual menu item in the File menu
> because this feature is useful for everyone.
> Just imagine trying to undelete a tab in a web browser,
> then failing to do this when the browser requires
> to enable a special mode to undelete tabs.  We can't afford
> to make Emacs more bizarre than it currently is, that
> would scare away users.
>
> Then I recalled that the main argument in the discussion
> against enabling this by default was the memory occupied
> by 16 deleted frames.
>
> So to simplify this I proposed a new option with the default value 1
> instead of the hard-coded number 16.  Then waited for 3 days
> that is standard practice.  And no comments means that everyone agreed
> with this improvement.

Here is the patch that fixes all these problems: