GNU bug report logs - #1305
All code that currently beeps should use visual bell instead

Previous Next

Full log

Message #655 received at 1305 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Gregory Heytings <gregory <at> heytings.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Wed, 21 Apr 2021 08:11:04 -0500

Gregory Heytings <gregory <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.