From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nikolay Kudryavtsev Newsgroups: gmane.emacs.bugs Subject: bug#68663: Unsaved buffers dialog is unhelpful Date: Sun, 28 Jan 2024 20:21:31 +0300 Message-ID: References: <86ede3824s.fsf@gnu.org> <6593db7e-a065-4d07-89e8-775f7e8cd90e@gmail.com> <86v87e7ro4.fsf@gnu.org> <03c24873-b7d6-4fe5-8fff-5e71882271d5@gmail.com> <86r0i27pop.fsf@gnu.org> <81ca484b-c26b-4798-9a75-4ac5b1c54eab@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27786"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 68663@debbugs.gnu.org To: Stefan Kangas , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 28 18:22:10 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rU8rC-00071S-Ar for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Jan 2024 18:22:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rU8r0-0000AO-1Y; Sun, 28 Jan 2024 12:21:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rU8qw-00009z-85 for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2024 12:21:54 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rU8qv-00046c-W1 for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2024 12:21:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rU8r3-0003Hv-Nd for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2024 12:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Nikolay Kudryavtsev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Jan 2024 17:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68663 X-GNU-PR-Package: emacs Original-Received: via spool by 68663-submit@debbugs.gnu.org id=B68663.170646251012622 (code B ref 68663); Sun, 28 Jan 2024 17:22:01 +0000 Original-Received: (at 68663) by debbugs.gnu.org; 28 Jan 2024 17:21:50 +0000 Original-Received: from localhost ([127.0.0.1]:58295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rU8qs-0003HV-5L for submit@debbugs.gnu.org; Sun, 28 Jan 2024 12:21:50 -0500 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:54742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rU8qp-0003HI-Ro for 68663@debbugs.gnu.org; Sun, 28 Jan 2024 12:21:48 -0500 Original-Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2cf42ca9bb2so23663101fa.1 for <68663@debbugs.gnu.org>; Sun, 28 Jan 2024 09:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706462494; x=1707067294; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=+ZlUd860rnx5yNUGiyVY/PJtfODk2fAo3VWI/TbmP4Y=; b=ZzasfwVuuQEiWesmVolyBhfDpquYYkGgc87TA4n6GMM2H9ZgvAe2vjZ+SsO1oTVj90 RPie7qiUJHKX8FeIRNhiBxCyn+Og93GYsFRdrBgRY+GFpC//+RsQ5Tv6dcqG3bc62vZV eT5wjDEaNflzMaMRQOvM9clxiv4l+pXsl/uDm5qemvMJBoYzI0YKVItswyMBYw8FAL5n nf7U6UNiVWAg+X0sNLqqVFonTp7lc1dJsFieUybwuExG2RcWeVKpPPjenx+uTRvczo3O csq56rFgo1AZs4J5q+VYkrZWjblPHEr/eZSzYk4Pd6vOrNnDVzLDML2nB2FR6BypYvhP sC3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706462494; x=1707067294; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+ZlUd860rnx5yNUGiyVY/PJtfODk2fAo3VWI/TbmP4Y=; b=o/yvCYVKOpeHlS2KmSoWIuajj3xFeUWLHyDQOX4HTMOn4ViUYsAv6w1h+scRDpndl0 Ds3ka6aNUaU9bKPU2AR0Sjmnho4nu8IHYpNY0RxYbSdj4dY5kR8H4yT//3FDm7Wgb6ud nCnRCs/5+wrfnmQNcIUfqmWdRfzDB5lfox6q9InunTJKUKsqAb2paGPYMo1p10CqdMKV j9kTxxUTL4S3OxbgOccJmTcvAyaUpx7D8C58BiCccXe0CnrvCIlSUpIeeKdM3hmXjg+6 KV3P+sYmdM6HKnXUv7zX3baQ/SqHmDo3BWVt3EDgrty9+V2yPaYl1jnAfOckDIxBMQfp s0hg== X-Gm-Message-State: AOJu0Yw8XrJWDJzkPsWrt6lt2Y08xt6JtcGYh5oSoh3b3JEJ0o95oIsO X05vCs7tiw+Z9JiCoMRguw1a/8MEGtUxcrrkE8ZJp8kDMUkZJi/+ X-Google-Smtp-Source: AGHT+IHRGTkc3WbeCpVFdq3BUomnx3ir3Bhg15memu4qrE9MOwv4y0hJ6vB4nMwuWbCtyl6NBegnaA== X-Received: by 2002:a2e:97d1:0:b0:2cc:9435:a5f8 with SMTP id m17-20020a2e97d1000000b002cc9435a5f8mr2183708ljj.6.1706462493735; Sun, 28 Jan 2024 09:21:33 -0800 (PST) Original-Received: from ?IPV6:2a02:2168:b3fc:9700:7b17:ef39:815:1d38? ([2a02:2168:b3fc:9700:7b17:ef39:815:1d38]) by smtp.gmail.com with ESMTPSA id q5-20020a2e2a05000000b002cf1fd75e88sm853949ljq.14.2024.01.28.09.21.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jan 2024 09:21:33 -0800 (PST) X-Google-Original-From: Nikolay Kudryavtsev Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279095 Archived-At: 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.