bug#1305: All code that currently beeps should use visual bell instead

[Stefan Monnier <monnier@iro.umontreal.ca>]

> AFAICS in other editors error signals are far less frequent (e.g. they do
>  nothing when you try to move past the beginning or end of the buffer, or
>  when you press a key binding with no corresponding action, or when you
>  enter characters in a read-only file, ...), they only signal "critical"
>  errors.  So I'm not sure it's possible to get inspired by what they
>  do. What they use are typically popups; I attach two examples with Visual
>  Studio and Atom, one when a non-readable file is opened, another when
>  a non-writable file is saved.

This suggests we may want to introduce "levels" of beeping.
We generally follow the convention that a command should do *something*
so if the command cannot do what the user asked because it is
"obviously" non-sensical (e.g. try to move before the beginning or past
the end of the buffer, type a key that's not bound, ...) we'd emit
a "low-priority" beep, whereas in case of an actual error we'd emit
a higher priority beep.  We probably don't need many levels, (e.g. just
2, at most 3 might be enough).

Not sure it's worth the trouble, since it could require a fair bit of
changes in a lot of code.  But it would let users configure their Emacs
to be similarly "discrete" as the editors you describe.


        Stefan