Re: ding - too often (OS X and in general)

[Kevin Gallagher]

> > Quitting rings the bell because you do it with the bell character,
> > C-g.  Also, it works by causing something almost indistiguishable from
> > an error.
>
> Of course we could distinguish them.  I do think it's important to do
> something when execution is interrupted by C-g so the user can tell the
> difference between normal and abnormal termination.  But I can see the 
> point
> in making this feedback different than the one corresponding to an error.

Don't forget, one can always set the variable visible-bell to replace the 
ding with a visible flashing in Emacs.  But this replaces the ding in all 
situations with the visible flashing, which the user might not want.

As an alternative, it might be reasonable to consider adding a new feature 
which enables visible-bell for aborts issued by the user from the keyboard 
and, possibly, a few other bell-ringing keyboard inputs (like trying to move 
point beyond the beginning or end of the buffer), but otherwise ring the 
bell for all other error conditions.  In this way, the user would still have 
a notification that a C-g was entered (or that an attempt to move beyond the 
end of the buffer failed).

Some kind of "abort entered" notification is particularly helpful to signal 
the user, when a typo results in a C-g being entered, to explain an 
otherwise mysterious occurance.

Kevin


----- Original Message ----- 
From: "Stefan Monnier" <address@hidden>
To: <address@hidden>
Cc: "David Reitter" <address@hidden>; <address@hidden>
Sent: Tuesday, May 24, 2005 8:37 AM
Subject: Re: ding - too often (OS X and in general)


> > Quitting rings the bell because you do it with the bell character,
> > C-g.  Also, it works by causing something almost indistiguishable from
> > an error.
>
> Of course we could distinguish them.  I do think it's important to do
> something when execution is interrupted by C-g so the user can tell the
> difference between normal and abnormal termination.  But I can see the 
> point
> in making this feedback different than the one corresponding to an error.
>
>
>        Stefan
>
>
> _______________________________________________
> Emacs-pretest-bug mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug