GNU bug report logs - #68663
Unsaved buffers dialog is unhelpful

Previous Next

To reply to this bug, email your comments to 68663 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Unsaved buffers dialog is unhelpful
Date: Mon, 22 Jan 2024 23:37:25 +0300

Hello.

Ever since 29.1 there's been a regression in user prompts when closing 
Emacs with multiple modified buffers. Now user only gets 3 options:

- Close without saving

- Save all

- Cancel

In 28.2 and earlier, for every buffer, the user would get the prompt 
asking to save the file and the following options:

-Yes(save the file)

-No(don't)

-View This Buffer

-View This Buffer And Quit

-View Changes in This Buffer

-Save This Buffer But No More

-Save All Buffers

-No For All

I would argue that, while the old dialog may have been over-complicated 
in terms of user options, the new dialog is useless. The only two 
options available are the ones that a reasonable user would never use. 
So he has to press cancel and then lets hope he knows about M-x 
save-some-buffers.

While restoring the old dialog would certainly be an improvement over 
the current situation, maybe some options should be trimmed from it to 
avoid overwhelming the user with too many options and maybe the whole 
thing should be ported to a minibuffer prompt(made into a front-end over 
save-some-buffers). It's 2024 and we no longer have to pretend that the 
90s GUI conventions are the future.

I can see that there's been some debate over this on emacs-devel, back 
in 2022:

https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01727.html

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>, 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Tue, 23 Jan 2024 01:41:12 +0200

On 22/01/2024 22:37, Nikolay Kudryavtsev wrote:
> While restoring the old dialog would certainly be an improvement over 
> the current situation, maybe some options should be trimmed from it to 
> avoid overwhelming the user with too many options and maybe the whole 
> thing should be ported to a minibuffer prompt(made into a front-end over 
> save-some-buffers). It's 2024 and we no longer have to pretend that the 
> 90s GUI conventions are the future.

Maybe it could allow presenting a combined diff, rather than showing the 
diffs for the buffers one by one.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 13:08:35 +0200

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Mon, 22 Jan 2024 23:37:25 +0300
> 
> Hello.
> 
> Ever since 29.1 there's been a regression in user prompts when closing 
> Emacs with multiple modified buffers. Now user only gets 3 options:
> 
> - Close without saving
> 
> - Save all
> 
> - Cancel
> 
> In 28.2 and earlier, for every buffer, the user would get the prompt 
> asking to save the file and the following options:
> 
> -Yes(save the file)
> 
> -No(don't)
> 
> -View This Buffer
> 
> -View This Buffer And Quit
> 
> -View Changes in This Buffer
> 
> -Save This Buffer But No More
> 
> -Save All Buffers
> 
> -No For All

I can only reproduce this when exiting Emacs via the menu-bar, by
clicking File->Quit.  If I exit Emacs with "C-x C-c", I see in Emacs
29 the same options as in Emacs 28.

> I would argue that, while the old dialog may have been over-complicated 
> in terms of user options, the new dialog is useless. The only two 
> options available are the ones that a reasonable user would never use. 

I disagree, FWIW.  I think they are the 2 most important options.

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

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 17:40:32 +0300

Ha, that's funny. I'm so set in my habit of quitting the gui Emacs by 
pressing the close button, that I had no idea that C-x C-c does anything 
different there.

So the big question here is this: what's going to be the dev team's 
decision on the idea of getting rid of the pop up dialog entirely and 
replacing it with C-x C-c(save-some-buffers) minibuffer prompt? Provided 
some work is done to it, to make it more (new) user friendly. Of course 
some care should also be taken to keep all the advanced functionality too.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 16:54:35 +0200

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Sat, 27 Jan 2024 17:40:32 +0300
> Cc: 68663 <at> debbugs.gnu.org
> 
> So the big question here is this: what's going to be the dev team's 
> decision on the idea of getting rid of the pop up dialog entirely and 
> replacing it with C-x C-c(save-some-buffers) minibuffer prompt?

You can have it already in your customizations: set use-dialog-box to
nil.

Getting rid of dialog boxes entirely is out of the question, since
Emacs always prompts with a dialog box when some command was invoked
from the menu bar by clicking the mouse.  This is very old behavior,
and we cannot change it, not even for a single command.  Sorry.

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

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 18:21:35 +0300

Right, makes sense.

What about improving the current dialog, restoring at least some of the 
pre-29 behavior?

Maybe add some option that allows jumping into the save-some-buffers 
buffers prompt.

P.S. Thanks for the use-dialog-box tip.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 17:37:26 +0200

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Sat, 27 Jan 2024 18:21:35 +0300
> Cc: 68663 <at> debbugs.gnu.org
> 
> Right, makes sense.
> 
> What about improving the current dialog, restoring at least some of the 
> pre-29 behavior?
> 
> Maybe add some option that allows jumping into the save-some-buffers 
> buffers prompt.

I'd prefer to hear more opinions.  The change which you dislike was
done on purpose, so I'm reluctant to revert it unless enough people
agree with you.

Stefan, WDYT?

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 13:18:07 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
>> Date: Sat, 27 Jan 2024 18:21:35 +0300
>> Cc: 68663 <at> debbugs.gnu.org
>>
>> Right, makes sense.
>>
>> What about improving the current dialog, restoring at least some of the
>> pre-29 behavior?
>>
>> Maybe add some option that allows jumping into the save-some-buffers
>> buffers prompt.
>
> I'd prefer to hear more opinions.  The change which you dislike was
> done on purpose, so I'm reluctant to revert it unless enough people
> agree with you.
>
> Stefan, WDYT?

I'd rather not go back on that change, indeed.  It was done not only on
purpose, but after a discussion where all involved welcomed the change:
https://debbugs.gnu.org/4980

I think this is a wontfix at this point.  Sorry, Nikolay.

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

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sun, 28 Jan 2024 01:38:56 +0300

That's very unfortunate.

I'll summarize the arguments for changing this dialog for the future, 
because I have a hunch that this would eventually be changed:

From the point of view of a power user this is bad because power users 
generally have Emacs running for day-weeks-months at a time and they 
generally need to know whether the change they've made to some buffer 
days ago is meaningful or a typo. The new behavior requires them to set 
use-dialog-box nil or remember about the C-x C-c behavior being 
different. All for a basic thing that ideally should not take any mental 
space.

From the point of view of a new user this is bad because now the user 
is stuck searching for those modified buffers by hand since Emacs have 
not given him any guidance. Quitting and saving is such a basic 
operation(cue two pages of vim jokes) that at this point we should not 
only not expect the user to know about M-x save-some-buffers, but even 
what the buffer modified mode line flag looks like.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sat, 27 Jan 2024 15:31:14 -0800

Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com> writes:

> That's very unfortunate.
>
> I'll summarize the arguments for changing this dialog for the future,
> because I have a hunch that this would eventually be changed:
>
>  From the point of view of a power user this is bad because power users
> generally have Emacs running for day-weeks-months at a time and they
> generally need to know whether the change they've made to some buffer
> days ago is meaningful or a typo. The new behavior requires them to set
> use-dialog-box nil or remember about the C-x C-c behavior being
> different. All for a basic thing that ideally should not take any mental
> space.

Thanks.  I think the old dialog was a complete mess myself, as did
others, so I think simply reverting to it is the a no-go.

However, we might be more amenable to a well-thought out proposal for
what an improved dialogue might look like in 2024.  I'm not saying that
we would accept it, but I'm not prepared to close any doors either.

The fact that we recently changed it means that it would have to be a
solid proposal for us to accept it, though.  Mere tweaks to get some old
favorite feature back are not likely to fly.

Good arguments here might include:

 - "I have looked at how VSCode does this, a project with significant
   resources to pour into things like dedicated UX experts, and here is
   what they do.  We might want to do something similar, because ..."

>  From the point of view of a new user this is bad because now the user
> is stuck searching for those modified buffers by hand since Emacs have
> not given him any guidance. Quitting and saving is such a basic
> operation(cue two pages of vim jokes) that at this point we should not
> only not expect the user to know about M-x save-some-buffers, but even
> what the buffer modified mode line flag looks like.

I didn't check, but it sounds like this might point to a real problem.
Could you please describe in more detail the workflow that you have in
mind?  What is the exact situation when you see the problem, and why?

Bonus points for coming up with other ideas to improve the situation
than reverting or a complete redesign.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
Cc: stefankangas <at> gmail.com, 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sun, 28 Jan 2024 07:54:49 +0200

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
> Date: Sun, 28 Jan 2024 01:38:56 +0300
> Cc: 68663 <at> debbugs.gnu.org
> 
>  From the point of view of a new user this is bad because now the user 
> is stuck searching for those modified buffers by hand since Emacs have 
> not given him any guidance.

Showing the modified buffers is easy: use "C-x C-b", and you will see
a clear indication which buffer is modified.

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

From: Nikolay Kudryavtsev <nikolay.kudryavtsev <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 68663 <at> debbugs.gnu.org
Subject: Re: bug#68663: Unsaved buffers dialog is unhelpful
Date: Sun, 28 Jan 2024 20:21:31 +0300

In terms of detailed change proposals, my experience tells me that it's 
usually best to test the waters first, see whether there are things that 
I haven't considered initially(there were) and what are the acceptable 
options, both technically and culturally.

> I didn't check, but it sounds like this might point to a real problem.
> Could you please describe in more detail the workflow that you have in
> mind?  What is the exact situation when you see the problem, and why?
In this use case we're talking about a very new user. Lets say this is 
your first time(day) of using Emacs. You don't know about M-x 
save-some-buffers, you're not going to quit with C-x C-c, you don't know 
about C-x C-b, you don't know what the * on the modeline is, you don't 
even know what a modeline is. But before 29 you could still quit Emacs 
and have a decent level of protection from making any unwanted edits. I 
think it's pretty natural for users to often restart any less than 
familiar application when they're thinking that they're doing something 
harmful.

So that's two of the use cases. I've also re-read the previous 
discussions on this topic, to try and present the main use case that is 
benefited by the previous change.

I think the only people who are ONLY doing save all or save none are the 
people who are working on projects with limited scopes in a very 
controlled environment - e.g. the user is usually only making edits 
within a single VC repository(project) and thus every time he quits he 
does not particularly care about the unsaved buffers either way, because 
were the changes in them valuable in any way he'd already have committed 
them. For this use case any extra notification is just an annoyance for 
the user. Maybe to further accommodate such users, there should be an 
easy option to disable any unsaved buffers dialog outright.

Now that we have the use case established, lets also honestly question 
what was so bad about the previous behavior, when we're only looking to 
accommodate this single use case? The same 2 buttons were available 
before, just as they are available now. It was just that there were 
other visually(logically and mentally) distracting other options. Which 
to me does not seem like a problem worthy of sacrificing the other use 
cases to, but obviously YMMV.

Also I think something should be said about this being an instant versus 
vs an incremental operation. Where stuff like a combined diff as 
suggested by Dmitry or the act-able modified buffer list as originally 
suggested by the reporter in #4980 would have some tangible advantages 
in convenience, especially the more straightforward your usage is.

The act-able buffer list seems like a perfect solution here 
convenience-wise, but the way I understand it, it's not feasible 
technically.

As for taking inspiration from other editors, I just had a quick look at 
5 other editors\IDEs I had on hand and basically all the IDEs present 
very much the same act-able buffer list.

The smaller editors generally prefer to avoid asking user anything, 
avoid saving anything and then just restoring the changes on restart. 
Which is another perfectly fine solution that's a no-go for us here. 
Though it may be worth considering as an eventual option, because it 
seems like a perfect fit for the limited scope editing use-case 
described above.

Previous Next

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