Horrible new unsaved buffers dialog

Horrible new unsaved buffers dialog

[Po Lu]

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.

Re: Horrible new unsaved buffers dialog

[Lars Ingebrigtsen]

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

Re: Horrible new unsaved buffers dialog

[Tomas Hlavaty]

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]

Re: Horrible new unsaved buffers dialog

[Tomas Hlavaty]

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.

Re: Horrible new unsaved buffers dialog

[Sergey Organov]

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

Re: Horrible new unsaved buffers dialog

[Po Lu]

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.

Re: Horrible new unsaved buffers dialog

[Lars Ingebrigtsen]

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

Re: Horrible new unsaved buffers dialog

[Phil Sainty]

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

Re: Horrible new unsaved buffers dialog

[Lars Ingebrigtsen]

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

Re: Horrible new unsaved buffers dialog

[Po Lu]

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.

Re: Horrible new unsaved buffers dialog

[Phil Sainty]

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.

Re: Horrible new unsaved buffers dialog

[Po Lu]

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

> Can dialogs have checkboxes?

They can't either, at least on X.

Re: Horrible new unsaved buffers dialog

[Lars Ingebrigtsen]

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

Re: Horrible new unsaved buffers dialog

[Po Lu]

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.

Re: Horrible new unsaved buffers dialog

[Phil Sainty]

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

Re: Horrible new unsaved buffers dialog

[xenodasein--- via Emacs development discussions.]

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.

Re: Horrible new unsaved buffers dialog

[Po Lu]

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.