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

From: Gregory Heytings <[email-masked]>
Date: Fri, 30 Apr 2021 07:13:23 +0000

>> 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).
>

Indeed.  You may have seen that this is what my patch does, except that 
instead of hard-coding the error levels, it lets each user decide which 
errors they want to see with a flashing effect and which errors they want 
to see without flashing effect.