unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Horrible new unsaved buffers dialog
       [not found] <87y230iqfr.fsf.ref@yahoo.com>
@ 2022-01-28  1:45 ` Po Lu
  2022-01-28 13:55   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu @ 2022-01-28  1:45 UTC (permalink / raw)
  To: emacs-devel

The dialog that would show up when you picked File -> Quit from the menu
bar used to show a dialog for each unsaved file's buffer with several
handy options to view and act on the buffer and unsaved changes.

In this morning's master, it only shows a single "unsaved buffers"
dialog, which is completely inadequate when there is more than one
unsaved file.  I don't understand why this change was made which turns
said dialog box from a convenient feature into an eyesore.

Thanks.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-28  1:45 ` Horrible new unsaved buffers dialog Po Lu
@ 2022-01-28 13:55   ` Lars Ingebrigtsen
  2022-01-28 20:10     ` Tomas Hlavaty
                       ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-28 13:55 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> In this morning's master, it only shows a single "unsaved buffers"
> dialog, which is completely inadequate when there is more than one
> unsaved file.  I don't understand why this change was made which turns
> said dialog box from a convenient feature into an eyesore.

The old dialog box was incomprehensible and user hostile.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-28 13:55   ` Lars Ingebrigtsen
@ 2022-01-28 20:10     ` Tomas Hlavaty
  2022-01-28 20:14       ` Tomas Hlavaty
  2022-01-29  9:07       ` Sergey Organov
  2022-01-29  0:52     ` Po Lu
  2022-01-29  0:53     ` Phil Sainty
  2 siblings, 2 replies; 17+ messages in thread
From: Tomas Hlavaty @ 2022-01-28 20:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Po Lu; +Cc: emacs-devel

On Fri 28 Jan 2022 at 14:55, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Po Lu <luangruo@yahoo.com> writes:
>
>> In this morning's master, it only shows a single "unsaved buffers"
>> dialog, which is completely inadequate when there is more than one
>> unsaved file.  I don't understand why this change was made which turns
>> said dialog box from a convenient feature into an eyesore.
>
> The old dialog box was incomprehensible and user hostile.

Why does Emacs pops up native dialog at all?

Even the minibuffer based version is not so convenient.

Would not it be better to show a new buffer listing all the unsaved
changes and relevant buttons in one place, not sequentially popping up
in dialog or minibuffer?

Something like:

Modified buffers exist.
  [Save all buffers and quit]
  [Exit anyway]
Save file /tmp/a?
  [Save]
  [Discard changes]
  [View]
  [View and quit]
  [View changes]
  [Save this but no more]
Save file /tmp/b?
  [Save]
  [Discard changes]
  [View]
  [View and quit]
  [View changes]
  [Save this but no more]
Save file /tmp/c?
  [Save]
  [Discard changes]
  [View]
  [View and quit]
  [View changes]
  [Save this but no more]



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-28 20:10     ` Tomas Hlavaty
@ 2022-01-28 20:14       ` Tomas Hlavaty
  2022-01-29  9:07       ` Sergey Organov
  1 sibling, 0 replies; 17+ messages in thread
From: Tomas Hlavaty @ 2022-01-28 20:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Po Lu; +Cc: emacs-devel

On Fri 28 Jan 2022 at 21:10, Tomas Hlavaty <tom@logand.com> wrote:
> On Fri 28 Jan 2022 at 14:55, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> In this morning's master, it only shows a single "unsaved buffers"
>>> dialog, which is completely inadequate when there is more than one
>>> unsaved file.  I don't understand why this change was made which turns
>>> said dialog box from a convenient feature into an eyesore.
>>
>> The old dialog box was incomprehensible and user hostile.
>
> Why does Emacs pops up native dialog at all?
>
> Even the minibuffer based version is not so convenient.
>
> Would not it be better to show a new buffer listing all the unsaved
> changes and relevant buttons in one place, not sequentially popping up
> in dialog or minibuffer?
>
> Something like:
>
> Modified buffers exist.
>   [Save all buffers and quit]
>   [Exit anyway]
> Save file /tmp/a?
>   [Save]
>   [Discard changes]
>   [View]
>   [View and quit]
>   [View changes]
>   [Save this but no more]
> Save file /tmp/b?
>   [Save]
>   [Discard changes]
>   [View]
>   [View and quit]
>   [View changes]
>   [Save this but no more]
> Save file /tmp/c?
>   [Save]
>   [Discard changes]
>   [View]
>   [View and quit]
>   [View changes]
>   [Save this but no more]

Additionally [Save this but no more] is probably redundant and could be
omitted.  Also [View and quit] could be omitted.  If user clicks [Save]
or [Discard changes], remove the Save file item from the buffer.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-28 13:55   ` Lars Ingebrigtsen
  2022-01-28 20:10     ` Tomas Hlavaty
@ 2022-01-29  0:52     ` Po Lu
  2022-01-29 14:39       ` Lars Ingebrigtsen
  2022-01-29  0:53     ` Phil Sainty
  2 siblings, 1 reply; 17+ messages in thread
From: Po Lu @ 2022-01-29  0:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The old dialog box was incomprehensible and user hostile.

I don't want to bikeshed over this (even though I disagree), so could we
please put the new dialog behind a user option?

It needs a NEWS entry as well.

Thanks in advance.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-28 13:55   ` Lars Ingebrigtsen
  2022-01-28 20:10     ` Tomas Hlavaty
  2022-01-29  0:52     ` Po Lu
@ 2022-01-29  0:53     ` Phil Sainty
  2 siblings, 0 replies; 17+ messages in thread
From: Phil Sainty @ 2022-01-29  0:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Po Lu, emacs-devel

On 2022-01-29 02:55, Lars Ingebrigtsen wrote:
> The old dialog box was incomprehensible and user hostile.

I think the old dialog box was for the *most* part both
comprehensible and (by providing useful options) user friendly.

The button I'd consider removing is "save this but no more",
because the user isn't being shown which other buffers that
will affect.  Of course "No for all" is the same, but the
latter is saying "I don't care about this session" whereas
the former suggests that the user does care about the session
to some extent.  Others might disagree, though.

"View this buffer and quit" is a useful button, but worded
in a confusing way, as "quit" could either mean "exit emacs"
or "do not exit emacs".  The "exit emacs" interpretation
doesn't make a lot of sense in context, and yet if the user
doesn't *want* to exit emacs they are going to be hesitant
to make assumptions.  Perhaps "Edit this buffer" would be a
better label.

I think that everything else is both useful and very clear.

The new dialog is unquestionably a lot simpler, but I don't
think that's a good thing.  If the reason for this change is
that other programs don't have "quit" dialogs which are useful
as the Emacs version, I don't think that's a good reason to
make the Emacs version less useful.  I would instead argue
that other programs would benefit from more useful dialogs.

I think the original dialog could be improved by making it
more *sophisticated* by providing the user with an overview
of all the unsaved buffers, but IMO this extreme simplification
is a step backwards.

The original dialog provided a streamlined way for the user
to do all the sorts of things which they will likely need
to do in this situation.  By removing those options you haven't
removed the user's need to do those things, but you've made
it harder for them to do it.


-Phil




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-28 20:10     ` Tomas Hlavaty
  2022-01-28 20:14       ` Tomas Hlavaty
@ 2022-01-29  9:07       ` Sergey Organov
  1 sibling, 0 replies; 17+ messages in thread
From: Sergey Organov @ 2022-01-29  9:07 UTC (permalink / raw)
  To: Tomas Hlavaty; +Cc: Po Lu, Lars Ingebrigtsen, emacs-devel

Tomas Hlavaty <tom@logand.com> writes:

> On Fri 28 Jan 2022 at 14:55, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> In this morning's master, it only shows a single "unsaved buffers"
>>> dialog, which is completely inadequate when there is more than one
>>> unsaved file.  I don't understand why this change was made which turns
>>> said dialog box from a convenient feature into an eyesore.
>>
>> The old dialog box was incomprehensible and user hostile.
>
> Why does Emacs pops up native dialog at all?
>
> Even the minibuffer based version is not so convenient.
>
> Would not it be better to show a new buffer listing all the unsaved
> changes and relevant buttons in one place, not sequentially popping up
> in dialog or minibuffer?
>
> Something like:
>
> Modified buffers exist.
>   [Save all buffers and quit]
>   [Exit anyway]
> Save file /tmp/a?
>   [Save]
>   [Discard changes]
>   [View]
>   [View and quit]
>   [View changes]
>   [Save this but no more]
> Save file /tmp/b?
>   [Save]
>   [Discard changes]
>   [View]
>   [View and quit]
>   [View changes]
>   [Save this but no more]
> Save file /tmp/c?
>   [Save]
>   [Discard changes]
>   [View]
>   [View and quit]
>   [View changes]
>   [Save this but no more]

This idea to have buffer rather dialog/minibuffer is rather appealing.
I'd like to have an option to bring such a buffer not only on Quit, but
on any invocation of 'save-some-buffers'.

It's also great to see "Discard changes" item that is not there in the
default minibuffer version of 'save-some-buffers'. I've unsuccessfully
tried to convince community it's useful enough to be there by default,
and I'm now locally use the following tweak to get the option:

#+BEGIN_SRC emacs-lisp
;; Support "revert buffer" in 'save-some-buffers'. Especially useful
;; for prompts when run 'compile' and friends.
(require 'files)
(push
  `(?R
    ,(lambda (buf)
      (with-current-buffer buf
        (revert-buffer)))
    "revert this buffer")
  save-some-buffers-action-alist)
#+END_SRC


Thanks,
-- Sergey Organov



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
@ 2022-01-29 10:40 xenodasein--- via Emacs development discussions.
  2022-01-29 11:39 ` Po Lu
  0 siblings, 1 reply; 17+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2022-01-29 10:40 UTC (permalink / raw)
  To: psainty; +Cc: emacs-devel

https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01754.htmlFrom: Phil Sainty> ...> The new dialog is unquestionably a lot simpler, but I don't> think that's a good thing.  If the reason for this change is> that other programs don't have "quit" dialogs which are useful> as the Emacs version, I don't think that's a good reason to> make the Emacs version less useful.  I would instead argue> that other programs would benefit from more useful dialogs.This argument is getting old, and not in a good way, wouldn't youagree?  Maybe it is wrong, and if it is not, this kind of elitismonly serves to drive others to alternatives.  Thinking of Lisp also.> I think the original dialog could be improved by making it> more *sophisticated* by providing the user with an overview> of all the unsaved buffers, but IMO this extreme simplification> is a step backwards.Simplicity is the ultimate sophistication.  I don't believe toosimple is a thing, it is either simple, or dysfunctional iftoo simple.> The original dialog provided a streamlined way for the user> to do all the sorts of things which they will likely need> to do in this situation.  By removing those options you haven't> removed the user's need to do those things, but you've made> it harder for them to do it.You say streamlined, I say kitchen sink.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-29 10:40 xenodasein--- via Emacs development discussions.
@ 2022-01-29 11:39 ` Po Lu
  0 siblings, 0 replies; 17+ messages in thread
From: Po Lu @ 2022-01-29 11:39 UTC (permalink / raw)
  To: xenodasein--- via Emacs development discussions.; +Cc: psainty, xenodasein

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01754.htmlFrom:
> Phil Sainty> ...> The new dialog is unquestionably a lot simpler, but
> I don't> think that's a good thing.  If the reason for this change is>
> that other programs don't have "quit" dialogs which are useful> as the
> Emacs version, I don't think that's a good reason to> make the Emacs
> version less useful.  I would instead argue> that other programs would
> benefit from more useful dialogs.This argument is getting old, and not
> in a good way, wouldn't youagree?  Maybe it is wrong, and if it is
> not, this kind of elitismonly serves to drive others to alternatives.
> Thinking of Lisp also.> I think the original dialog could be improved
> by making it> more *sophisticated* by providing the user with an
> overview> of all the unsaved buffers, but IMO this extreme
> simplification> is a step backwards.Simplicity is the ultimate
> sophistication.  I don't believe toosimple is a thing, it is either
> simple, or dysfunctional iftoo simple.> The original dialog provided a
> streamlined way for the user> to do all the sorts of things which they
> will likely need> to do in this situation.  By removing those options
> you haven't> removed the user's need to do those things, but you've
> made> it harder for them to do it.You say streamlined, I say kitchen
> sink.

It is hard to tell what you have posted and what was written by Phil
when you quote like this.  Perhaps you are using webmail, and your
particular webmail service's option to turn off HTML mail is broken?

> This argument is getting old, and not in a good way, wouldn't you
> agree?  Maybe it is wrong, and if it is not, this kind of elitism only
> serves to drive others to alternatives.  Thinking of Lisp also.

FTR, I have no particular opinion on which one is better for everyone.

All I want is some way to get the old dialogs back.  The new dialogs
make it impossible to do anything useful with a mouse, except to hit
"cancel" while I look for my keyboard.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-29  0:52     ` Po Lu
@ 2022-01-29 14:39       ` Lars Ingebrigtsen
  2022-01-29 21:48         ` Phil Sainty
  2022-01-30  1:00         ` Po Lu
  0 siblings, 2 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-29 14:39 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> I don't want to bikeshed over this (even though I disagree), so could we
> please put the new dialog behind a user option?

What would that user option be called?
kill-emacs-simple-dialog-box-when-called-from-the-menu?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-29 14:39       ` Lars Ingebrigtsen
@ 2022-01-29 21:48         ` Phil Sainty
  2022-01-30 15:57           ` Lars Ingebrigtsen
  2022-01-30  1:00         ` Po Lu
  1 sibling, 1 reply; 17+ messages in thread
From: Phil Sainty @ 2022-01-29 21:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Po Lu, emacs-devel

On 2022-01-30 03:39, Lars Ingebrigtsen wrote:
> Po Lu <luangruo@yahoo.com> writes:
>> I don't want to bikeshed over this (even though I disagree),
>> so could we please put the new dialog behind a user option?
> 
> What would that user option be called?
> kill-emacs-simple-dialog-box-when-called-from-the-menu?

I suggest `kill-emacs-minimal-mouse-dialog'.

And if the minimal version is the default, I think that the
dialog itself should contain a toggle to switch to the full
version.

How about a global `minimal-mouse-dialog-mode' though?

I've always thought it's great that when you trigger a query with
the keyboard Emacs prompts you via the minibuffer, and when you
trigger the same query via the mouse Emacs prompts you via a GUI
dialog, and that in both cases you get the same options -- but
conveniently offered for the input device that you were using at
that moment.

I'm not sure whether there are already other examples or if this
is the first, but this change feels like an instance of something
more general, in that triggering the command with the mouse is no
longer giving the same set of options to the user that they would
have had if they had used the keyboard.

A global mode would be a good way of saying "always give me the
same options" or "keep things more basic for mouse usage".


-Phil




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-29 14:39       ` Lars Ingebrigtsen
  2022-01-29 21:48         ` Phil Sainty
@ 2022-01-30  1:00         ` Po Lu
  1 sibling, 0 replies; 17+ messages in thread
From: Po Lu @ 2022-01-30  1:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> What would that user option be called?
> kill-emacs-simple-dialog-box-when-called-from-the-menu?

`kill-emacs-simple-dialog-for-menu' would work.

Thanks.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-29 21:48         ` Phil Sainty
@ 2022-01-30 15:57           ` Lars Ingebrigtsen
  2022-01-31  0:35             ` Po Lu
  0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-30 15:57 UTC (permalink / raw)
  To: Phil Sainty; +Cc: Po Lu, emacs-devel

Phil Sainty <psainty@orcon.net.nz> writes:

> And if the minimal version is the default, I think that the
> dialog itself should contain a toggle to switch to the full
> version.

A "more options..." button might be nice?  (But smaller than the other
buttons, I guess.)  

> How about a global `minimal-mouse-dialog-mode' though?

[...]

> A global mode would be a good way of saying "always give me the
> same options" or "keep things more basic for mouse usage".

I think that sounds good, but I'm not sure whether there are that many
other instances where the complicated dialogue box was as pathological
as the exit-emacs one?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-30 15:57           ` Lars Ingebrigtsen
@ 2022-01-31  0:35             ` Po Lu
  2022-01-31  0:45               ` Phil Sainty
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu @ 2022-01-31  0:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Phil Sainty, emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (But smaller than the other buttons, I guess.)

We don't have any code that allows for such buttons in dialog boxes yet,
FTR.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-31  0:35             ` Po Lu
@ 2022-01-31  0:45               ` Phil Sainty
  2022-01-31  2:21                 ` Po Lu
  0 siblings, 1 reply; 17+ messages in thread
From: Phil Sainty @ 2022-01-31  0:45 UTC (permalink / raw)
  To: Po Lu; +Cc: Lars Ingebrigtsen, emacs-devel

On 2022-01-31 13:35, Po Lu wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> (But smaller than the other buttons, I guess.)
> 
> We don't have any code that allows for such buttons in dialog boxes

Can dialogs have checkboxes?  I was initially imagining a
checkbox which would set the user option appropriately.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-31  0:45               ` Phil Sainty
@ 2022-01-31  2:21                 ` Po Lu
  2022-01-31 15:30                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu @ 2022-01-31  2:21 UTC (permalink / raw)
  To: Phil Sainty; +Cc: Lars Ingebrigtsen, emacs-devel

Phil Sainty <psainty@orcon.net.nz> writes:

> Can dialogs have checkboxes?

They can't either, at least on X.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Horrible new unsaved buffers dialog
  2022-01-31  2:21                 ` Po Lu
@ 2022-01-31 15:30                   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-31 15:30 UTC (permalink / raw)
  To: Po Lu; +Cc: Phil Sainty, emacs-devel

Po Lu <luangruo@yahoo.com> writes:

>> Can dialogs have checkboxes?
>
> They can't either, at least on X.

But it'd be really useful if they could.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2022-01-31 15:30 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <87y230iqfr.fsf.ref@yahoo.com>
2022-01-28  1:45 ` Horrible new unsaved buffers dialog Po Lu
2022-01-28 13:55   ` Lars Ingebrigtsen
2022-01-28 20:10     ` Tomas Hlavaty
2022-01-28 20:14       ` Tomas Hlavaty
2022-01-29  9:07       ` Sergey Organov
2022-01-29  0:52     ` Po Lu
2022-01-29 14:39       ` Lars Ingebrigtsen
2022-01-29 21:48         ` Phil Sainty
2022-01-30 15:57           ` Lars Ingebrigtsen
2022-01-31  0:35             ` Po Lu
2022-01-31  0:45               ` Phil Sainty
2022-01-31  2:21                 ` Po Lu
2022-01-31 15:30                   ` Lars Ingebrigtsen
2022-01-30  1:00         ` Po Lu
2022-01-29  0:53     ` Phil Sainty
2022-01-29 10:40 xenodasein--- via Emacs development discussions.
2022-01-29 11:39 ` Po Lu

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).