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

[Gregory Heytings]

> > So we'd change the default of the former to be a new visible bell 
> > function (for instance something that works the same as the visible 
> > bell on GNU/Linux systems, but across all systems (or one of the new 
> > proposed visible bell functions)), and deprecate `visible-bell'.  I 
> > think that should be a pretty un-annoying way forward.
>
> Fully agreed; it's an improvement over my proposal.
>
> This is currently handled in different ways on different platforms, so I 
> we might want to clean that up a bit while we're at it.

Yes, the idea would be to have new predefined values for 
ring-bell-function:

ring-bell-beep = the former visible-bell nil (when ring-bell-function was 
nil)

ring-bell-visible = the former visible-bell t (when ring-bell-function was 
nil), whose behavior differs depending on the platform

and a new prettier bell function, which would be the default.

> The main thing remaining, besides writing the actual patch, is to decide 
> what the visual bell should look like.  I am currently running with 
> Gregory's patch for testing; it would useful if others carried out 
> similar experiments with one or more variations mentioned in this thread

Thank you.  I recently improved the patch to handle the explicit 'ding' 
events more cleanly, see attached.  In that case, because 'ding' is 
usually followed by 'message', there is a short delay between the flash 
and the message, but that seems unavoidable (or at least I do not see how 
it could be avoided).  Note that the delay is already present with 
visible-bell t (and ring-bell-function nil).

New-default-bell.patch
Description: Text Data