Re: Canceling dialogues

Re: Canceling dialogues

[LENNART BORGMAN]

> I don't think it is a good idea to indiscriminately add a 
> Cancel/Quit 
> option that appears to the user to be of equal importance as the 
> Yes or 
> No (or any other valid) options. Especially as some dialogs may 
> already 
> have an option of that name that does something other than 
> keyboard-quit.

Then what do you think about letting ESC do what C-g does? Is not that actually what a user expects (at least on w32)?

Re: Canceling dialogues

[Mathias Dahl]

> Then what do you think about letting ESC do what C-g does? Is not that actually what a user expects (at least on w32)?

I think it is a good idea. I read some guideline some weeks ago that a
user should be able to close/cancel/quit all dialogs in Windows by
pressing ESC.

Re: Canceling dialogues

[LENNART BORGMAN]

From: Mathias Dahl <mathias.dahl@gmail.com>
Date: Thursday, August 3, 2006 11:46 am
Subject: Re: Canceling dialogues

> > > In my configuration, with Lucid menus, this does cause a quit. 
> It
> > > displays Quit in the echo area, and it does not execute the rest
> > > of the command.
> >
> > That's strange: I also checked in the configuration with X toolkit.
> > What command did you try?  I tried revert-buffer (invoked 
> through the
> > menu-bar's File menu).
> 
> The same happens for me, running the latest CVS Emacs under GNU/Linux
> + Gnome. C-g and ESC does the same, and I like it.
> 

Maybe you could be a bit more clear about what happened? ;-)

Re: Canceling dialogues

[Mathias Dahl]

> > The same happens for me, running the latest CVS Emacs under GNU/Linux
> > + Gnome. C-g and ESC does the same, and I like it.
> >
>
> Maybe you could be a bit more clear about what happened? ;-)

The same as what Richard experienced, i.e. a "Quit" message in the echo area.

Canceling dialogues

[Lennart Borgman]

If you use the menus in Emacs to call a function and this function for 
example calls y-or-n-p then a popup dialog will be shown (if 
use-dialog-box is t). This dialog box can not be canceled, at least not 
on w32.

I think this is a bug and that a third alternative for canceling should 
be added.

Re: Canceling dialogues

[Eli Zaretskii]

> Date: Mon, 31 Jul 2006 19:38:15 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> If you use the menus in Emacs to call a function and this function for 
> example calls y-or-n-p then a popup dialog will be shown (if 
> use-dialog-box is t). This dialog box can not be canceled, at least not 
> on w32.

The problem is, this is not really a dialog, it's a menu.  We don't
yet support dialogs on Windows; the code to do that is #ifdef'ed away,
presumably because it isn't finished yet.  Volunteers are welcome to
work on that, but I don't think such changes should be done before the
release.

> I think this is a bug and that a third alternative for canceling should 
> be added.

The menu only has YES and NO, so that's what is displayed.

Re: Canceling dialogues

[Lennart Borgman]

Eli Zaretskii wrote:
>   
>> I think this is a bug and that a third alternative for canceling should 
>> be added.
>>     
>
> The menu only has YES and NO, so that's what is displayed.
>
>   
Yes ... - I was suggesting that we should add a Cancel alternative. So I 
do not understand what you mean. Can you explain?

Re: Canceling dialogues

[Eli Zaretskii]

> Date: Mon, 31 Jul 2006 21:36:19 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >   
> >> I think this is a bug and that a third alternative for canceling should 
> >> be added.
> >>     
> >
> > The menu only has YES and NO, so that's what is displayed.
> >
> >   
> Yes ... - I was suggesting that we should add a Cancel alternative. So I 
> do not understand what you mean. Can you explain?

When Emacs wants to pop the YES/NO dialog, it calls the function
x-popup-dialog (Fx_popup_dialog), which in the Windows port currently
creates a menu instead of a dialog and pops that menu.  This function
(x-popup-dialog) is a general-purpose function, it doesn't know, nor
care, what it gets as the contents of the dialog.  It isn't called
only for the YES/NO type of dialog, you can have other dialogs with
arbitrary long lists of alternatives.

So, unless we somehow program the function to discover that it is
called for YES/NO dialog, we cannot blithely add a CANCEL button to
it.

If you meant to add code to x-popup-dialog that would recognize this
special case, I think fixing the generic dialog code is a better
investment of our resources and energy, and the result is going to be
much cleaner.

In addition, there's the question what to do for CANCEL, as someone
else pointed out.

Re: Canceling dialogues

[Lennart Borgman]

Eli Zaretskii wrote:
> When Emacs wants to pop the YES/NO dialog, it calls the function
> x-popup-dialog (Fx_popup_dialog), which in the Windows port currently
> creates a menu instead of a dialog and pops that menu.  This function
> (x-popup-dialog) is a general-purpose function, it doesn't know, nor
> care, what it gets as the contents of the dialog.  It isn't called
> only for the YES/NO type of dialog, you can have other dialogs with
> arbitrary long lists of alternatives.
>
> So, unless we somehow program the function to discover that it is
> called for YES/NO dialog, we cannot blithely add a CANCEL button to
> it.
>   
Why not add a cancel alternative for the other calls too?

> If you meant to add code to x-popup-dialog that would recognize this
> special case, I think fixing the generic dialog code is a better
> investment of our resources and energy, and the result is going to be
> much cleaner.
>   
Yes, that would be better. But could not my suggestion be implemented 
with much less effort?
> In addition, there's the question what to do for CANCEL, as someone
> else pointed out.
>   
I tried to answer that in another message. It should do what C-g does 
for the command line alternative (minus some things that does not seem 
appropriate as David pointed out).

Re: Canceling dialogues

[Eli Zaretskii]

> Date: Mon, 31 Jul 2006 22:16:50 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> > So, unless we somehow program the function to discover that it is
> > called for YES/NO dialog, we cannot blithely add a CANCEL button to
> > it.
> >   
> Why not add a cancel alternative for the other calls too?

Because we cannot be sure that CANCEL makes sense in the context of
the dialog.

> > If you meant to add code to x-popup-dialog that would recognize this
> > special case, I think fixing the generic dialog code is a better
> > investment of our resources and energy, and the result is going to be
> > much cleaner.
> >   
> Yes, that would be better. But could not my suggestion be implemented 
> with much less effort?

Maybe so, but it's ugly and unclean, IMHO.

> I tried to answer that in another message. It should do what C-g does 
> for the command line alternative (minus some things that does not seem 
> appropriate as David pointed out).

C-g is a bad idea, I think: it's too violent.

Anyway, since it's a non-trivial change, I don't think we should
consider it at this time.  These ugly dialog emulations are with us
for a long time, so it's no disaster if we will have them for one more
release.

Re: Canceling dialogues

[Lennart Borgman]

Eli Zaretskii wrote:
>> Why not add a cancel alternative for the other calls too?
>>     
>
> Because we cannot be sure that CANCEL makes sense in the context of
> the dialog.
>   
I do not understand. If a dialog box is not used then C-g has a semantic 
today. I just suggest using the same semantics for dialog boxes (through 
the use of a new alternative).
> Maybe so, but it's ugly and unclean, IMHO.
>   
It is ugly, yes. Unclean? Not sure.
> C-g is a bad idea, I think: it's too violent.
>   
Why is it too violent when a dialog box is used (but not otherwise)?

Re: Canceling dialogues

[Richard Stallman]

    When Emacs wants to pop the YES/NO dialog, it calls the function
    x-popup-dialog (Fx_popup_dialog), which in the Windows port currently
    creates a menu instead of a dialog and pops that menu.  This function
    (x-popup-dialog) is a general-purpose function, it doesn't know, nor
    care, what it gets as the contents of the dialog.  It isn't called
    only for the YES/NO type of dialog, you can have other dialogs with
    arbitrary long lists of alternatives.

It is ok to add Cancel to every dialog box.
In my setup, which is GNU/Linux with GNOME, every dialog
window has a box with an x to cancel it, and that will have the effect
of causing a quit.  This is useful.

To add a Cancel option on systems which don't present the kill-window
box would be useful too.

If it is inconvenient to determine which systems have the kill-window
box, adding a Cancel option in every dialog would also be ok.
On systems where the window does have a kill-this-window box,
the Cancel option will be redundant, but not harmful.

Re: Canceling dialogues

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> Date: Mon, 31 Jul 2006 19:59:54 -0400
> 
> It is ok to add Cancel to every dialog box.
> [...]
> To add a Cancel option on systems which don't present the kill-window
> box would be useful too.

I really suggest not to make such changes before the release.  There's
no grave problem to solve here, AFAICS.

Re: Canceling dialogues

[Jan Djärv]

Eli Zaretskii skrev:
>> From: Richard Stallman <rms@gnu.org>
>> CC: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
>> Date: Mon, 31 Jul 2006 19:59:54 -0400
>>
>> It is ok to add Cancel to every dialog box.
>> [...]
>> To add a Cancel option on systems which don't present the kill-window
>> box would be useful too.
> 
> I really suggest not to make such changes before the release.  There's
> no grave problem to solve here, AFAICS.
> 

I agree.  On X at least, ESC and C-g should do cancel on dialogs and menus.  I 
thought ESC was standard on windows for this kind of thing?  Not really sure 
how it works on Mac, but I see there is code for canceling menus on C-g there 
as well, on OSX >= 10.3 at least.

	Jan D.

Re: Canceling dialogues

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>> The menu only has YES and NO, so that's what is displayed.
>>
>>   
> Yes ... - I was suggesting that we should add a Cancel alternative. So
> I do not understand what you mean. Can you explain?

What does "Cancel" mean, in the context of a Yes/No question? Doesn't
it mean the same as "No"?

Re: Canceling dialogues

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>>> The menu only has YES and NO, so that's what is displayed.
>>>
>>>   
>> Yes ... - I was suggesting that we should add a Cancel alternative. So
>> I do not understand what you mean. Can you explain?
>
> What does "Cancel" mean, in the context of a Yes/No question? Doesn't
> it mean the same as "No"?

Depends on the question.  For something like

    Save buffer before exiting?

it is actually a third choice.  For others it might be "No", but I am
not sure that it might not in some cases be "Yes".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Canceling dialogues

[Lennart Borgman]

Jason Rumney wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>>> The menu only has YES and NO, so that's what is displayed.
>>>
>>>   
>>>       
>> Yes ... - I was suggesting that we should add a Cancel alternative. So
>> I do not understand what you mean. Can you explain?
>>     
>
> What does "Cancel" mean, in the context of a Yes/No question? Doesn't
> it mean the same as "No"?
>   
Does not C-g cancel the last user command?

Re: Canceling dialogues

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Jason Rumney wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>
>>   
>>>> The menu only has YES and NO, so that's what is displayed.
>>>>
>>>>         
>>> Yes ... - I was suggesting that we should add a Cancel alternative. So
>>> I do not understand what you mean. Can you explain?
>>>     
>>
>> What does "Cancel" mean, in the context of a Yes/No question? Doesn't
>> it mean the same as "No"?
>>   
> Does not C-g cancel the last user command?

Not really.  It stops it dead in its track, but any progress that has
already been made before the dialog will remain.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Canceling dialogues

[Lennart Borgman]

David Kastrup wrote:
>> Does not C-g cancel the last user command?
>>     
>
> Not really.  It stops it dead in its track, but any progress that has
> already been made before the dialog will remain.
>   
Thanks. I meant stop of course, but my English is not that fluent.

Re: Canceling dialogues

[Richard Stallman]

    >> What does "Cancel" mean, in the context of a Yes/No question? Doesn't
    >> it mean the same as "No"?
    >>   
    > Does not C-g cancel the last user command?

    Not really.  It stops it dead in its track, but any progress that has
    already been made before the dialog will remain.

C-g cancels what the command is going to do.  Often, when the command
asks a question, that is a useful option.  People who write commands
know that quitting is a likely possibility whenever the command reads
input, and generally design the command to do the "real work" after it
asks the question.

Re: Canceling dialogues

[Jan Djärv]

Lennart Borgman skrev:
> Eli Zaretskii wrote:
>>  
>>> I think this is a bug and that a third alternative for canceling 
>>> should be added.
>>>     
>>
>> The menu only has YES and NO, so that's what is displayed.
>>
>>   
> Yes ... - I was suggesting that we should add a Cancel alternative. So I 
> do not understand what you mean. Can you explain?

Does not ESC cancel it?

	Jan D.

Re: Canceling dialogues

[Lennart Borgman]

Jan Djärv wrote:
>> Yes ... - I was suggesting that we should add a Cancel alternative. 
>> So I do not understand what you mean. Can you explain?
>
> Does not ESC cancel it?
Thanks for mentioning that. It removes the menu but the last user 
command continues. This is in my opinion also a bug.

If it would be possible to let ESC to stop the last user command (like 
C-g) then this would probably be the most inituitive behaviour. Then a 
"Cancel" alternative would perhaps be unnecessary.

Re: Canceling dialogues

[Stuart D. Herring]

> If you use the menus in Emacs to call a function and this function for
> example calls y-or-n-p then a popup dialog will be shown (if
> use-dialog-box is t). This dialog box can not be canceled, at least not
> on w32.
>
> I think this is a bug and that a third alternative for canceling should
> be added.

What should y-or-n-p return if the user chooses this alternative?  Should
it signal 'quit (like C-g would)?  What if `inhibit-quit' is t?  The idea
of an escape route for the user is not a bad one, but I wonder if the
notion of "cancelling" is insufficiently generalizable to apply to just
any use of `y-or-n-p'.  Is there a specific behavior that you would want
to associate with this?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Canceling dialogues

[Lennart Borgman]

Stuart D. Herring wrote:
> What should y-or-n-p return if the user chooses this alternative?  Should
> it signal 'quit (like C-g would)?  What if `inhibit-quit' is t?  The idea
> of an escape route for the user is not a bad one, but I wonder if the
> notion of "cancelling" is insufficiently generalizable to apply to just
> any use of `y-or-n-p'.  Is there a specific behavior that you would want
> to associate with this?
>   
I want the Cancel alternative to work just like C-g works in the command 
line alternative.

Re: Canceling dialogues

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Stuart D. Herring wrote:
>> What should y-or-n-p return if the user chooses this alternative?  Should
>> it signal 'quit (like C-g would)?  What if `inhibit-quit' is t?  The idea
>> of an escape route for the user is not a bad one, but I wonder if the
>> notion of "cancelling" is insufficiently generalizable to apply to just
>> any use of `y-or-n-p'.  Is there a specific behavior that you would want
>> to associate with this?
>>   
> I want the Cancel alternative to work just like C-g works in the
> command line alternative.

Well, it sounds like there would not be much of a point to display a
cancel button if inhibit-quit is t, and it would also appear
inappropriate to ring the bell (which is usually done for a lot of
situations where quit is signaled).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Canceling dialogues

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Stuart D. Herring wrote:
>>     
>>> What should y-or-n-p return if the user chooses this alternative?  Should
>>> it signal 'quit (like C-g would)?  What if `inhibit-quit' is t?  The idea
>>> of an escape route for the user is not a bad one, but I wonder if the
>>> notion of "cancelling" is insufficiently generalizable to apply to just
>>> any use of `y-or-n-p'.  Is there a specific behavior that you would want
>>> to associate with this?
>>>   
>>>       
>> I want the Cancel alternative to work just like C-g works in the
>> command line alternative.
>>     
>
> Well, it sounds like there would not be much of a point to display a
> cancel button if inhibit-quit is t, and it would also appear
> inappropriate to ring the bell (which is usually done for a lot of
> situations where quit is signaled).
>   
Good points.

Re: Canceling dialogues

[Richard Stallman]

    What should y-or-n-p return if the user chooses this alternative?  Should
    it signal 'quit (like C-g would)?

Yes, exactly.

      What if `inhibit-quit' is t?

Then the quit happens later.

      The idea
    of an escape route for the user is not a bad one, but I wonder if the
    notion of "cancelling" is insufficiently generalizable to apply to just
    any use of `y-or-n-p'.

Sure.  When y-or-n-p uses the keyboard, you can type C-g to do so.

Re: Canceling dialogues

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     What should y-or-n-p return if the user chooses this alternative?  Should
>     it signal 'quit (like C-g would)?
>
> Yes, exactly.
>
>       What if `inhibit-quit' is t?
>
> Then the quit happens later.

There won't be a "later" until an alternative is selected.  It think
it would be quite confusing if the menu appeared to do nothing, and
then clicking on either "Yes" or "No" would trigger a quit later on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Canceling dialogues

[Richard Stallman]

    There won't be a "later" until an alternative is selected.  It think
    it would be quite confusing if the menu appeared to do nothing, and
    then clicking on either "Yes" or "No" would trigger a quit later on.

Maybe that means it is a mistake to call y-or-n-p with inhibit-quit set.

Re: Canceling dialogues

[Richard Stallman]

    If you use the menus in Emacs to call a function and this function for 
    example calls y-or-n-p then a popup dialog will be shown (if 
    use-dialog-box is t). This dialog box can not be canceled, at least not 
    on w32.

    I think this is a bug and that a third alternative for canceling should 
    be added.

Normally you can type C-g in the Emacs window to quit out ofthe
dialog.  (I don't know whether this works on Windows.)  Nonetheless,
adding "Quit" as an alternative would not be a bad thing -- for all
platforms.

Would someone like to do that?

Re: Canceling dialogues

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 31 Jul 2006 18:17:33 -0400
> Cc: emacs-devel@gnu.org
> 
> Normally you can type C-g in the Emacs window to quit out ofthe
> dialog.  (I don't know whether this works on Windows.)

It doesn't, currently.  I will try to look into it when I have time.

However, at least on my system, if I click anywhere outside the
dialog, the dialog pops down.  Lennart, didn't you say you were unable
to do so?  If the dialog can easily be popped down, perhaps all the
solutions discussed in this thread are not needed.

> Nonetheless, adding "Quit" as an alternative would not be a bad
> thing -- for all platforms.
> 
> Would someone like to do that?

Do we really want to add such new features at this time?

Re: Canceling dialogues

[Lennart Borgman]

Eli Zaretskii wrote:
> However, at least on my system, if I click anywhere outside the
> dialog, the dialog pops down.  Lennart, didn't you say you were unable
> to do so?  If the dialog can easily be popped down, perhaps all the
> solutions discussed in this thread are not needed.
>   
The dialog pops down, but the user command continues.

Re: Canceling dialogues

[Eli Zaretskii]

> Date: Tue, 01 Aug 2006 08:39:21 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  rms@gnu.org,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > However, at least on my system, if I click anywhere outside the
> > dialog, the dialog pops down.  Lennart, didn't you say you were unable
> > to do so?  If the dialog can easily be popped down, perhaps all the
> > solutions discussed in this thread are not needed.
> >   
> The dialog pops down, but the user command continues.

Doesn't that happen on Unix and GNU/Linux?

Re: Canceling dialogues

[Eli Zaretskii]

> Date: Tue, 01 Aug 2006 08:39:21 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  rms@gnu.org,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > However, at least on my system, if I click anywhere outside the
> > dialog, the dialog pops down.  Lennart, didn't you say you were unable
> > to do so?  If the dialog can easily be popped down, perhaps all the
> > solutions discussed in this thread are not needed.
> >   
> The dialog pops down, but the user command continues.

I've now checked on GNU/Linux, and the dialogs behave there in exactly
the same manner: even if you click the "X" button in the upper-right
corner of the dialog, to close the dialog, the command continues; you
need to type some character to stop it.

So I think the Windows port behaves exactly like the X version here,
with the sole exception of C-g.  I will look into fixing the C-g case
when I have time (if no one beats me to it), but other than that, I
don't think we have a problem here that needs to be fixed before the
release.  (One could argue that the fact that the command continues
after closing the dialog is a bug or misfeature on all platforms, but
since this is so at least since v21.x, and probably long before that,
I think we can safely live with it until after the release.)

Re: Canceling dialogues

[Lennart Borgman]

Eli Zaretskii wrote:
> I've now checked on GNU/Linux, and the dialogs behave there in exactly
> the same manner: even if you click the "X" button in the upper-right
> corner of the dialog, to close the dialog, the command continues; you
> need to type some character to stop it.
>   
Thanks for checking. However I think Emacs behaviour here is a bug. I 
believe most (at least most new) users will expect the command to be 
canceled. (Compare for example the guidelines Mathias mentioned.)

It looks safe to me to fix this before the release. I mean I find it 
hard to believe that it could interfere with something (except some 
users expecting the old behaviour of course).

Re: Canceling dialogues

[Eli Zaretskii]

> Date: Wed, 02 Aug 2006 08:10:25 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  rms@gnu.org,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > I've now checked on GNU/Linux, and the dialogs behave there in exactly
> > the same manner: even if you click the "X" button in the upper-right
> > corner of the dialog, to close the dialog, the command continues; you
> > need to type some character to stop it.
> >   
> Thanks for checking. However I think Emacs behaviour here is a bug.

Arguably, yes.  I wrote that in my message.

> It looks safe to me to fix this before the release.

The safety of fixing it depends on what the fix is.  Based on my
knowledge of the intricacies of handling events that happen while
certain widgets belonging to the toolkit are active, I'm guessing that
the fix will not be simple; any non-trivial change in this area runs a
high risk of breaking something UI-related (we had examples of this
just a few days ago, with Emacs frame positioning on Windows).

I could be wrong, of course, so if someone shows how to fix this
``easily'', I will probably change my mind.

> I mean I find it 
> hard to believe that it could interfere with something (except some 
> users expecting the old behaviour of course).

You are talking about _intended_ consequences, whereas I fear the
_unintended_ ones.

Re: Canceling dialogues

[Richard Stallman]

    The safety of fixing it depends on what the fix is.  Based on my
    knowledge of the intricacies of handling events that happen while
    certain widgets belonging to the toolkit are active, I'm guessing that
    the fix will not be simple; any non-trivial change in this area runs a
    high risk of breaking something UI-related (we had examples of this
    just a few days ago, with Emacs frame positioning on Windows).

Indeed, if the fix is risky, we do not want to install it now.
People can writing the fix, and then we will see if it is safe.

Re: Canceling dialogues

[Richard Stallman]

    I've now checked on GNU/Linux, and the dialogs behave there in exactly
    the same manner: even if you click the "X" button in the upper-right
    corner of the dialog, to close the dialog, the command continues; you
    need to type some character to stop it.

In my configuration, with Lucid menus, this does cause a quit.  It
displays Quit in the echo area, and it does not execute the rest
of the command.

That's what it ought to do in other configurations also.

Re: Canceling dialogues

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> Date: Wed, 02 Aug 2006 17:20:53 -0400
> 
>     I've now checked on GNU/Linux, and the dialogs behave there in exactly
>     the same manner: even if you click the "X" button in the upper-right
>     corner of the dialog, to close the dialog, the command continues; you
>     need to type some character to stop it.
> 
> In my configuration, with Lucid menus, this does cause a quit.  It
> displays Quit in the echo area, and it does not execute the rest
> of the command.

That's strange: I also checked in the configuration with X toolkit.
What command did you try?  I tried revert-buffer (invoked through the
menu-bar's File menu).

Re: Canceling dialogues

[Mathias Dahl]

> > In my configuration, with Lucid menus, this does cause a quit.  It
> > displays Quit in the echo area, and it does not execute the rest
> > of the command.
>
> That's strange: I also checked in the configuration with X toolkit.
> What command did you try?  I tried revert-buffer (invoked through the
> menu-bar's File menu).

The same happens for me, running the latest CVS Emacs under GNU/Linux
+ Gnome. C-g and ESC does the same, and I like it.

Re: Canceling dialogues

[Richard Stallman]

    That's strange: I also checked in the configuration with X toolkit.
    What command did you try?  I tried revert-buffer (invoked through the
    menu-bar's File menu).

I defined a command

(defun foo ()
  (interactive)
  (y-or-n-p "Foo? ")
  (setq foo t))

and bound it to C-M-mouse-1 using global-set-key.
Then I did C-M-mouse-1, and it brought up the dialog box.
Then I clicked on the X to kill the dialog box.
Emacs displayed Quit, and the variable foo was still unbound.

Re: Canceling dialogues

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> I defined a command
>
> (defun foo ()
>   (interactive)
>   (y-or-n-p "Foo? ")
>   (setq foo t))
>
> and bound it to C-M-mouse-1 using global-set-key.
> Then I did C-M-mouse-1, and it brought up the dialog box.
> Then I clicked on the X to kill the dialog box.
> Emacs displayed Quit, and the variable foo was still unbound.

There were some changes in xmenu.c from Dec 2004 and May 2005 that
were not also made in w32menu.c. I have added the code to Quit and
this now works on w32 also, but there are many more changes that may
be relevant (there are also many changes from that timeframe related
to supporting GTK menus, so it is difficult to find which changes are
relevant).

If someone has time, it is worth going through the ChangeLog looking
at changes that have been made in xmenu, xterm and xfns and seeing if
equivalent changes have been made in mac and w32 files, if not,
judging whether the change is relevant to other platforms.

I probably last did this sometime around mid-2004, so you won't need
to go further back than that.

Re: Canceling dialogues

[Jason Rumney]

Eli Zaretskii wrote:
> However, at least on my system, if I click anywhere outside the
> dialog, the dialog pops down.
This is true of Menus in general on Windows. Also, the ESC key has the 
same effect.
When dialogs are implemented properly on Windows, they will have X 
buttons, like Gnome dialogs.

I don't think it is a good idea to indiscriminately add a Cancel/Quit 
option that appears to the user to be of equal importance as the Yes or 
No (or any other valid) options. Especially as some dialogs may already 
have an option of that name that does something other than keyboard-quit.

Re: Canceling dialogues

[Richard Stallman]

    > Normally you can type C-g in the Emacs window to quit out ofthe
    > dialog.  (I don't know whether this works on Windows.)

    It doesn't, currently.  I will try to look into it when I have time.

This seems to be a bug on whatever platform you are using.

    > Nonetheless, adding "Quit" as an alternative would not be a bad
    > thing -- for all platforms.
    > 
    > Would someone like to do that?

    Do we really want to add such new features at this time?

It would be a workaround for a bug.
If it is the right thing to do, we can do it.

We are waiting for people to fix the bugs listed in FOR-RELEASE.