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

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> Yes, it's perhaps a bit unfortunate that "visible-bell" is nil in this
> case, but note that with visible-bell t and ring-bell-function ignore you
> also do not have what you could expect.  The semantics of visible-bell and
> ring-bell-function are a bit unclear, but they cannot be fixed anymore
> without introducing backward incompatible changes.

I think this is a bit of a mess, indeed.

I would be in favour of fixing this by adding one or more new variables
with reasonable semantics.  For example, why not have a variable called
`alarm-bell' with these valid values:

    - a function    call this function
    - `visual'      Use a visual bell
    - t             Ring the bell
    - nil           Do nothing

We should be able to do that while declaring the old variables obsolete,
and preserving their semantics meanwhile, especially given that both
`visible-bell' and `ring-bell-function' is nil by default.

>> My #1 preference would be to make it all behave like (setq visible-bell
>> t) on GNU/Linux does. This way we both get a proven behavior with no
>> significant complaints, as well as consistency across platforms.
>
> I understand that you're accustomed to what visible-bell t does on
> GNU/Linux, but frankly, its ugly.  Ask their opinion to non-Emacs users
> about that bell, I'd be surprised if they like it.

That's a good point, IMO.  But Dmitry's argument is also fairly
compelling.

For my money, the Doom idea, to flash the mode line in a different
color, is the most good looking one.  It is also hard to miss, and
doesn't risk hiding or obscuring the minibuffer.

I have used this for a couple of days and find it strictly better than
both the default behavior on GNU/Linux with inverse video and flashing
the minibuffer background.

Did anyone have any objections to doing it that way?