* bug#68663: Unsaved buffers dialog is unhelpful @ 2024-01-22 20:37 Nikolay Kudryavtsev 2024-01-22 23:41 ` Dmitry Gutov 2024-01-27 11:08 ` Eli Zaretskii 0 siblings, 2 replies; 12+ messages in thread From: Nikolay Kudryavtsev @ 2024-01-22 20:37 UTC (permalink / raw) To: 68663 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-22 20:37 bug#68663: Unsaved buffers dialog is unhelpful Nikolay Kudryavtsev @ 2024-01-22 23:41 ` Dmitry Gutov 2024-01-27 11:08 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Dmitry Gutov @ 2024-01-22 23:41 UTC (permalink / raw) To: Nikolay Kudryavtsev, 68663 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-22 20:37 bug#68663: Unsaved buffers dialog is unhelpful Nikolay Kudryavtsev 2024-01-22 23:41 ` Dmitry Gutov @ 2024-01-27 11:08 ` Eli Zaretskii 2024-01-27 14:40 ` Nikolay Kudryavtsev 1 sibling, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2024-01-27 11:08 UTC (permalink / raw) To: Nikolay Kudryavtsev; +Cc: 68663 > From: Nikolay Kudryavtsev <nikolay.kudryavtsev@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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 11:08 ` Eli Zaretskii @ 2024-01-27 14:40 ` Nikolay Kudryavtsev 2024-01-27 14:54 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Nikolay Kudryavtsev @ 2024-01-27 14:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 68663 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 14:40 ` Nikolay Kudryavtsev @ 2024-01-27 14:54 ` Eli Zaretskii 2024-01-27 15:21 ` Nikolay Kudryavtsev 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2024-01-27 14:54 UTC (permalink / raw) To: Nikolay Kudryavtsev; +Cc: 68663 > From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> > Date: Sat, 27 Jan 2024 17:40:32 +0300 > Cc: 68663@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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 14:54 ` Eli Zaretskii @ 2024-01-27 15:21 ` Nikolay Kudryavtsev 2024-01-27 15:37 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Nikolay Kudryavtsev @ 2024-01-27 15:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 68663 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 15:21 ` Nikolay Kudryavtsev @ 2024-01-27 15:37 ` Eli Zaretskii 2024-01-27 21:18 ` Stefan Kangas 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2024-01-27 15:37 UTC (permalink / raw) To: Nikolay Kudryavtsev, Stefan Kangas; +Cc: 68663 > From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> > Date: Sat, 27 Jan 2024 18:21:35 +0300 > Cc: 68663@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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 15:37 ` Eli Zaretskii @ 2024-01-27 21:18 ` Stefan Kangas 2024-01-27 22:38 ` Nikolay Kudryavtsev 0 siblings, 1 reply; 12+ messages in thread From: Stefan Kangas @ 2024-01-27 21:18 UTC (permalink / raw) To: Eli Zaretskii, Nikolay Kudryavtsev; +Cc: 68663 Eli Zaretskii <eliz@gnu.org> writes: >> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> >> Date: Sat, 27 Jan 2024 18:21:35 +0300 >> Cc: 68663@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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 21:18 ` Stefan Kangas @ 2024-01-27 22:38 ` Nikolay Kudryavtsev 2024-01-27 23:31 ` Stefan Kangas 2024-01-28 5:54 ` Eli Zaretskii 0 siblings, 2 replies; 12+ messages in thread From: Nikolay Kudryavtsev @ 2024-01-27 22:38 UTC (permalink / raw) To: Stefan Kangas, Eli Zaretskii; +Cc: 68663 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 22:38 ` Nikolay Kudryavtsev @ 2024-01-27 23:31 ` Stefan Kangas 2024-01-28 17:21 ` Nikolay Kudryavtsev 2024-01-28 5:54 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Stefan Kangas @ 2024-01-27 23:31 UTC (permalink / raw) To: Nikolay Kudryavtsev, Eli Zaretskii; +Cc: 68663 Nikolay Kudryavtsev <nikolay.kudryavtsev@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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 23:31 ` Stefan Kangas @ 2024-01-28 17:21 ` Nikolay Kudryavtsev 0 siblings, 0 replies; 12+ messages in thread From: Nikolay Kudryavtsev @ 2024-01-28 17:21 UTC (permalink / raw) To: Stefan Kangas, Eli Zaretskii; +Cc: 68663 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#68663: Unsaved buffers dialog is unhelpful 2024-01-27 22:38 ` Nikolay Kudryavtsev 2024-01-27 23:31 ` Stefan Kangas @ 2024-01-28 5:54 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2024-01-28 5:54 UTC (permalink / raw) To: Nikolay Kudryavtsev; +Cc: stefankangas, 68663 > From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> > Date: Sun, 28 Jan 2024 01:38:56 +0300 > Cc: 68663@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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-01-28 17:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-22 20:37 bug#68663: Unsaved buffers dialog is unhelpful Nikolay Kudryavtsev 2024-01-22 23:41 ` Dmitry Gutov 2024-01-27 11:08 ` Eli Zaretskii 2024-01-27 14:40 ` Nikolay Kudryavtsev 2024-01-27 14:54 ` Eli Zaretskii 2024-01-27 15:21 ` Nikolay Kudryavtsev 2024-01-27 15:37 ` Eli Zaretskii 2024-01-27 21:18 ` Stefan Kangas 2024-01-27 22:38 ` Nikolay Kudryavtsev 2024-01-27 23:31 ` Stefan Kangas 2024-01-28 17:21 ` Nikolay Kudryavtsev 2024-01-28 5:54 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.