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

Previous Next

To reply to this bug, email your comments to 1305 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Tue, 4 Nov 2008 17:51:13 -0500

By default, Emacs makes an audible beep every time the user makes an
error.  It would be great if you could please change the default
either:

1.  To not make any audible or visible bell when the user makes an
error.  (This would be best.)

2.  Or to use a visible bell only.  (This would be an acceptable
alternative.  Plus, Emacs already knows how to show a visible bell.)

If you do not change the default, some Emacs newbies may decide not to
use Emacs, but to use other editors instead, perhaps non-Free ones.
Here are three reasons why they may decide that:

A.  Some users find that the beep is harsh and unpleasant to the ear.

B.  Most apps beep only when something very bad happens.  But Emacs
beeps even upon minor mistakes like scrolling past end of buffer, or
pressing an unassigned key.  It even beeps on non-mistakes like
pressing C-g.  The amount of beeping may make users uncomfortable.

C.  Some Emacs newbies try Emacs for the first time at the office.  At
the office, ten or more people may hear each beep.  The feeling of
having distracted coworkers may make users even more uncomfortable.

You might say, "So newbies should disable the beep themselves".  No.
They may not bother.

You might say, "But if not for the beep, users won't notice errors".
No.  They will notice.  Human eyes notice significant onscreen changes
(perhaps 3 words or more) easily.

Regards,
Jason Spiro

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Xavier Maillard <xma <at> gnu.org>
To: Jason Spiro <jasonspiro4 <at> gmail.com>, 1305 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org, bug-submit-list <at> donarmstrong.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: Please disable the audible bell by default,
	to avoid discouraging newbies in crowded offices and elsewhere
Date: Wed, 5 Nov 2008 08:25:06 +0100

Hi,

I do not think it is a good idea to change this. You know, GNU
Emacs is also used by visually impaired and blind users and we
*must* satisfy these user class too. It is not a matter of
newbiness. Plus, resetting this setting is covered by many howto
and resources over the Internet so it should be pretty easy to
disable it for any user.

After that, if users prefer not to use emacs for such thing,
that's okay, go and choose another editor. Any user for any
editor should just RTFM when they start using it. I guess this is
an universal requirement when starting to use any software; emacs
is no exception.

Regards

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Message #20 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: "Xavier Maillard" <xma <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org,
        bug-submit-list <at> donarmstrong.com
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Thu, 6 Nov 2008 03:34:40 -0500

Hi Xavier,

Re. users with vision loss:  They need a screen reader (Emacspeak
provides that) or a magnifier utility.  But why do they also need
beep-on-error?  I started a thread at
http://news.gmane.org/gmane.emacs.emacspeak.general today to ask if
they really need it.  And if they do need it, remember they're in the
minority.  Will they truly mind searching online to learn how to
enable it?

Re. searching online and reading the documentation:  Users don't want
to waste time on that.  They want to spend their time getting things
done.  Let's make Emacs an editor for getting things done.

-Jason

Message #30 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Peter Rayner <peter.rayner <at> lsce.ipsl.fr>
To: 1305 <at> debbugs.gnu.org
Subject: OT: Should the Emacs team leave beep-on-error enabled for the sake of people with vision loss?
Date: Thu, 6 Nov 2008 11:25:45 +0100

Provided it can be turned off I would leave it on by default.  If my
emacspeak doesn't come up talking it's nice to get *some* feedback
that something is alive.
cheers
Peter


-- 
Peter Rayner: LSCE/IPSL, Laboratoire CEA-CNRS-UVSQ
address: Bat. 701 LSCE - CEA de Saclay
Orme des Merisiers, 91191 Gif/Yvette
work: +33  (1) 69 08 88 11;	mobile: +33 (6) 75 46 56 52;	 fax: +33 (1) 69 08 77 16
mail-to: peter.rayner <at> lsce.ipsl.fr
web: http://www-lsce.cea.fr/Pisp/52/peter.rayner.html

Message #35 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: john.sturdy <at> ul.ie
To: 1305 <at> debbugs.gnu.org
Subject: emacs beep
Date: Thu, 6 Nov 2008 21:11:24 +0000

I'm sighted, and I find the beep useful.

__John

Message #38 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Jason Spiro <jasonspiro4 <at> gmail.com>
Cc: 1305 <at> debbugs.gnu.org
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Thu, 6 Nov 2008 15:34:21 -0800 (PST)

"Jason Spiro" <jasonspiro4 <at> gmail.com> writes:

  > By default, Emacs makes an audible beep every time the user makes an
  > error.  It would be great if you could please change the default
  > either:
  > 
  > 1.  To not make any audible or visible bell when the user makes an
  > error.  (This would be best.)
  > 
  > 2.  Or to use a visible bell only.  (This would be an acceptable
  > alternative.  Plus, Emacs already knows how to show a visible bell.)
  > 
  > If you do not change the default, some Emacs newbies may decide not to
  > use Emacs, but to use other editors instead, perhaps non-Free ones.
  > Here are three reasons why they may decide that:
  > 
  > A.  Some users find that the beep is harsh and unpleasant to the ear.
  > 
  > B.  Most apps beep only when something very bad happens.  But Emacs
  > beeps even upon minor mistakes like scrolling past end of buffer, or
  > pressing an unassigned key.  It even beeps on non-mistakes like
  > pressing C-g.  The amount of beeping may make users uncomfortable.
  > 
  > C.  Some Emacs newbies try Emacs for the first time at the office.  At
  > the office, ten or more people may hear each beep.  The feeling of
  > having distracted coworkers may make users even more uncomfortable.

FWIW, I find the beep annoying and useless too.  I disable it in .emacs,
but every time I have to use emacs -Q to debug something it gets on my
nerves....

Message #43 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1305 <at> debbugs.gnu.org, Jason Spiro <jasonspiro4 <at> gmail.com>
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Thu, 06 Nov 2008 21:19:34 -0500

> FWIW, I find the beep annoying and useless too.  I disable it in .emacs,
> but every time I have to use emacs -Q to debug something it gets on my
> nerves....

I hate all forms of beeping.  So I'm definitely in favor of using the
visual bell by default, tho I never dared to propose it, seeing how it's
not even in the "Options" menu.


        Stefan

Message #48 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: peter.rayner <at> lsce.ipsl.fr
Cc: 1305 <at> debbugs.gnu.org
Subject: Re: bug#1305: OT: Should the Emacs team leave beep-on-error enabled for the sake of people with vision loss?
Date: Thu, 06 Nov 2008 21:28:12 -0500

> Provided it can be turned off I would leave it on by default.  If my
> emacspeak doesn't come up talking it's nice to get *some* feedback
> that something is alive.

The emacspeak config should simply include a (setq visible-bell nil) at
the very beginning.


        Stefan

Message #53 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jason Spiro <jasonspiro4 <at> gmail.com>, 1305 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: Please disable the audible bell by default,	to avoid discouraging newbies in crowded offices and elsewhere
Date: Fri, 07 Nov 2008 12:32:53 +0200

> Date: Tue, 4 Nov 2008 17:51:13 -0500
> From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
> Cc: 
> 
> By default, Emacs makes an audible beep every time the user makes an
> error.  It would be great if you could please change the default
> either:
> 
> 1.  To not make any audible or visible bell when the user makes an
> error.  (This would be best.)

Many other GUI applications beep under some circumstances that need
user attention.

> B.  Most apps beep only when something very bad happens.  But Emacs
> beeps even upon minor mistakes like scrolling past end of buffer, or
> pressing an unassigned key.  It even beeps on non-mistakes like
> pressing C-g.  The amount of beeping may make users uncomfortable.

Maybe we should simply revisit the places where we bitch-at-user, and
remove the beep from some of them.

But I don't see anything bad in beeping under extreme circumstances,
and don't support disabling it entirely.

> You might say, "But if not for the beep, users won't notice errors".
> No.  They will notice.  Human eyes notice significant onscreen changes
> (perhaps 3 words or more) easily.

The problem is, without the beep, the screen sometimes does not change
at all.  And that is BAD, from the HE point of view, at least IMO.

Message #63 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, Jason Spiro <jasonspiro4 <at> gmail.com>,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Fri, 07 Nov 2008 09:54:02 -0500

>> By default, Emacs makes an audible beep every time the user makes an
>> error.  It would be great if you could please change the default either:
>> 1.  To not make any audible or visible bell when the user makes an
>> error.  (This would be best.)
> Many other GUI applications beep under some circumstances that need
> user attention.

Actually, in my experience it's very rare for "modern" GUI applications
to beep.

>> B.  Most apps beep only when something very bad happens.  But Emacs
>> beeps even upon minor mistakes like scrolling past end of buffer, or
>> pressing an unassigned key.  It even beeps on non-mistakes like
>> pressing C-g.  The amount of beeping may make users uncomfortable.

> Maybe we should simply revisit the places where we bitch-at-user, and
> remove the beep from some of them.

> But I don't see anything bad in beeping under extreme circumstances,
> and don't support disabling it entirely.

I agree on the principle to beep in extreme circumstances, but since
these are rare (by definition of "extreme"), we should probably attack
from the other side: use the visible-bell by default, and add a new
function that does an actual beep (additionally to the visual bell) and
then try and find the few places where it's warranted.

>> You might say, "But if not for the beep, users won't notice errors".
>> No.  They will notice.  Human eyes notice significant onscreen changes
>> (perhaps 3 words or more) easily.

> The problem is, without the beep, the screen sometimes does not change
> at all.  And that is BAD, from the HE point of view, at least IMO.

That sounds like a bug to me.  In which circumstances does the
visible-bell fail to work?


        Stefan

Message #73 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 1305 <at> debbugs.gnu.org, jasonspiro4 <at> gmail.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Fri, 07 Nov 2008 18:52:03 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 1305 <at> emacsbugs.donarmstrong.com,  Jason Spiro <jasonspiro4 <at> gmail.com>,  bug-gnu-emacs <at> gnu.org
> Date: Fri, 07 Nov 2008 09:54:02 -0500
> 
> > The problem is, without the beep, the screen sometimes does not change
> > at all.  And that is BAD, from the HE point of view, at least IMO.
> 
> That sounds like a bug to me.  In which circumstances does the
> visible-bell fail to work?

I didn't mean visible-bell fails to work, I meant if we abolish any
visual or audible signs.  The OP asked as his 1st choice to disable
the beep, not replace it with visible-bell.

Message #83 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, jasonspiro4 <at> gmail.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Fri, 07 Nov 2008 13:48:31 -0500

>> That sounds like a bug to me.  In which circumstances does the
>> visible-bell fail to work?

> I didn't mean visible-bell fails to work, I meant if we abolish any
> visual or audible signs.  The OP asked as his 1st choice to disable
> the beep, not replace it with visible-bell.

Oh, that would be a clear "no", indeed.  Of course we'd replace it with
the visible-bell (and I suspect that OP also intended it that way).


        Stefan

Message #93 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: control <at> debbugs.gnu.org
Cc: "Eli Zaretskii" <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
        bug-gnu-emacs <at> gnu.org, "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Subject: Re: bug#1305: All code that currently beeps should use visual bell instead
Date: Sat, 8 Nov 2008 20:50:59 -0500

retitle 1305 All code that currently beeps should use visual bell instead
thanks

2008/11/7 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> Oh, that would be a clear "no", indeed.  Of course we'd replace it with
> the visible-bell (and I suspect that OP also intended it that way).

I didn't intend it that way:  the visual bell is also annoying, though
less annoying than the audible bell.  But fair enough.  :)  Retitling
accordingly.

Message #105 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Jason Spiro'" <jasonspiro4 <at> gmail.com>, <1305 <at> debbugs.gnu.org>,
        <control <at> debbugs.gnu.org>
Cc: <bug-gnu-emacs <at> gnu.org>
Subject: RE: bug#1305: All code that currently beeps should use visual bellinstead
Date: Sat, 8 Nov 2008 19:57:59 -0800

> All code that currently beeps should use visual bell instead
> 
> > Oh, that would be a clear "no", indeed.  Of course we'd 
> > replace it with
> > the visible-bell (and I suspect that OP also intended it that way).
> 
> I didn't intend it that way:  the visual bell is also annoying, though
> less annoying than the audible bell.  But fair enough.  :)  Retitling
> accordingly.

IIUC, that sounds terrible, to me. Today, one can simply turn off (or down) the
sound at the computer level and have zero distraction from the bell. That is not
unusual for users who share an office - it's not unlike turning down the volume
of a telephone ring.

This possibility of turning off or down the bell at the computer level should
not be removed. If Emacs just replaces the bell by the visible bell everywhere,
that will introduce lots of distraction. And unlike the bell, which has variable
volume, the visible bell is all-or-none.

What's wrong with leaving things as they have been since day one? Users who want
to turn off the bell can always do so, within Emacs or otherwise. Users should
be able to easily get any of these behaviors: (1) bell only, (2) visible bell
only, (3) bell and visible bell, (4) nothing. 

We should not systematically replace the bell by the visible bell just because
someone found the bell to be annoying. It's not difficult to turn off. Users
have been living with this option since the beginning.

Bell and visible bell should not really be regarded as replacements for each
other, in any case. They are two different ways to attract a user's attention.

And one is *not* less annoying than the other. At least not for all users in all
contexts. Each can be very annoying.

If you think there are currently too many places where Emacs beeps, try instead
to remove some of those beeps on a case-by-case basis. Don't just replace
beeping with flashing.

Message #115 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 1305 <at> debbugs.gnu.org, control <at> debbugs.gnu.org,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Sat, 8 Nov 2008 23:08:48 -0500

2008/11/8 Drew Adams <drew.adams <at> oracle.com> wrote:

> IIUC, that sounds terrible, to me. Today, one can simply turn off (or down) the
> sound at the computer level and have zero distraction from the bell. That is not
> unusual for users who share an office - it's not unlike turning down the volume
> of a telephone ring.
>
> This possibility of turning off or down the bell at the computer level should
> not be removed. If Emacs just replaces the bell by the visible bell everywhere,
> that will introduce lots of distraction. And unlike the bell, which has variable
> volume, the visible bell is all-or-none.

Many people don't know how to turn the PC speaker beep lower or off.
And IMO its volume is too high by default.  It can distract an entire
classroom.  That's 30+ people per beep.

> What's wrong with leaving things as they have been since day one? Users who want
> to turn off the bell can always do so, within Emacs or otherwise. Users should
> be able to easily get any of these behaviors: (1) bell only, (2) visible bell
> only, (3) bell and visible bell, (4) nothing.

OK, can we make that an option on the Options menu?  Should I file a
new bug to request that?

> We should not systematically replace the bell by the visible bell just because
> someone found the bell to be annoying. It's not difficult to turn off. Users
> have been living with this option since the beginning.
>
> Bell and visible bell should not really be regarded as replacements for each
> other, in any case. They are two different ways to attract a user's attention.
>
> And one is *not* less annoying than the other. At least not for all users in all
> contexts. Each can be very annoying.

Fair enough.

> If you think there are currently too many places where Emacs beeps, try instead
> to remove some of those beeps on a case-by-case basis. Don't just replace
> beeping with flashing.

How do we remove them on a case-by case basis?  The beep from pressing
C-g perhaps is possible to remove individually.  But how about the
"End of buffer" one you get when you try to move the point past the
end of the buffer?  That is just a beep on (error).

Message #125 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>, 1305 <at> debbugs.gnu.org
Cc: jasonspiro4 <at> gmail.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual	bellinstead
Date: Sun, 09 Nov 2008 21:04:16 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 8 Nov 2008 19:57:59 -0800
> Cc: bug-gnu-emacs <at> gnu.org
> 
> This possibility of turning off or down the bell at the computer level should
> not be removed.

I think you are barking the wrong tree: no one suggested to remove the
possibility to shut up the bell.

> If you think there are currently too many places where Emacs beeps, try instead
> to remove some of those beeps on a case-by-case basis.

That is what I suggested in the first place, and I still think it's
the best alternative.

Message #135 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jason Spiro <jasonspiro4 <at> gmail.com>, 1305 <at> debbugs.gnu.org
Cc: drew.adams <at> oracle.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual	bellinstead
Date: Sun, 09 Nov 2008 21:17:27 +0200

> Date: Sat, 8 Nov 2008 23:08:48 -0500
> From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
> Cc: bug-gnu-emacs <at> gnu.org, 1305 <at> emacsbugs.donarmstrong.com,
> 	control <at> emacsbugs.donarmstrong.com
> 
> Many people don't know how to turn the PC speaker beep lower or off.

I have difficulty believing this.  Almost every computer has speakers
nowadays, and every kid plays with them all the time.  I know my kids
do.

> And IMO its volume is too high by default.

The volume is not under Emacs control, it depends on how the system is
set up.

> > If you think there are currently too many places where Emacs beeps, try instead
> > to remove some of those beeps on a case-by-case basis. Don't just replace
> > beeping with flashing.
> 
> How do we remove them on a case-by case basis?  The beep from pressing
> C-g perhaps is possible to remove individually.  But how about the
> "End of buffer" one you get when you try to move the point past the
> end of the buffer?

I see no problem with dealing with each case individually.  Just grep
the C sources for `bitch_at_user' and `Fding', and the Lisp sources
for `ding'.

Message #140 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>, <1305 <at> debbugs.gnu.org>
Cc: <jasonspiro4 <at> gmail.com>, <bug-gnu-emacs <at> gnu.org>
Subject: RE: bug#1305: All code that currently beeps should use visual	bellinstead
Date: Sun, 9 Nov 2008 11:19:43 -0800

> > This possibility of turning off or down the bell at the 
> > computer level should not be removed.
> 
> I think you are barking the wrong tree: no one suggested to remove the
> possibility to shut up the bell.

If the bell is systematically replaced by the visible bell, then turning off the
sound at the computer level will not remove the distraction. The sound
distraction, which you can easily turn off outside Emacs, will have been
replaced by a sight distraction, which you cannot.

> > If you think there are currently too many places where 
> > Emacs beeps, try instead to remove some of those beeps on a
> > case-by-case basis.
> 
> That is what I suggested in the first place, and I still think it's
> the best alternative.

Two votes, then.

Message #155 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 1305 <at> debbugs.gnu.org, jasonspiro4 <at> gmail.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual	bellinstead
Date: Sun, 09 Nov 2008 22:00:27 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <jasonspiro4 <at> gmail.com>, <bug-gnu-emacs <at> gnu.org>
> Date: Sun, 9 Nov 2008 11:19:43 -0800
> 
> > > This possibility of turning off or down the bell at the 
> > > computer level should not be removed.
> > 
> > I think you are barking the wrong tree: no one suggested to remove the
> > possibility to shut up the bell.
> 
> If the bell is systematically replaced by the visible bell, then turning off the
> sound at the computer level will not remove the distraction. The sound
> distraction, which you can easily turn off outside Emacs, will have been
> replaced by a sight distraction, which you cannot.

No, that's not the intent.  The intent is to make the visible bell the
default.  To turn it off, you turn off visible-bell, which makes Emacs
beep again, and then turn off the speakers.

Message #165 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Xavier Maillard <xma <at> gnu.org>
To: "Jason Spiro" <jasonspiro4 <at> gmail.com>
Cc: 1305 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org,
        bug-submit-list <at> donarmstrong.com
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Mon, 10 Nov 2008 00:25:03 +0100

   Hi Xavier,

   Re. users with vision loss:  They need a screen reader (Emacspeak
   provides that) or a magnifier utility.  But why do they also need
   beep-on-error?

What if the screen reader is not working correctly ? The visible
bell could be used to check that something, at least, is working.

Regards

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Message #170 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Xavier Maillard <xma <at> gnu.org>
To: peter.rayner <at> lsce.ipsl.fr, 1305 <at> debbugs.gnu.org
Cc: 1305 <at> debbugs.gnu.org, bug-submit-list <at> donarmstrong.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: OT: Should the Emacs team leave beep-on-error enabled for
	the sake of people with vision loss?
Date: Mon, 10 Nov 2008 00:25:07 +0100

   Provided it can be turned off I would leave it on by default.  If my
   emacspeak doesn't come up talking it's nice to get *some* feedback
   that something is alive.

Correct.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Message #185 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Reitter <david.reitter <at> gmail.com>
To: Xavier Maillard <xma <at> gnu.org>, 1305 <at> debbugs.gnu.org
Cc: peter.rayner <at> lsce.ipsl.fr, bug-gnu-emacs <at> gnu.org,
        bug-submit-list <at> donarmstrong.com
Subject: Re: bug#1305: OT: Should the Emacs team leave beep-on-error enabled for the sake of people with vision loss?
Date: Sun, 9 Nov 2008 19:34:28 -0500

[Message part 1 (text/plain, inline)]

On 9 Nov 2008, at 18:25, Xavier Maillard wrote:

>
>   Provided it can be turned off I would leave it on by default.  If my
>   emacspeak doesn't come up talking it's nice to get *some* feedback
>   that something is alive.
>
> Correct.

The audible bell is annoying and absolutely non-standard.  It was the  
first thing I turned off in my branch: having Emacs ping loudly  
whenever one reached the end or beginning of the buffer when  
scrolling, or when some key entered wasn't bound, was just not  
acceptable, be it in the open-space office environment or at home.

Why not turn it off by default, but offer a command-line option  
(besides the customization variable) to turn it on when desired?  One  
could even bind the (real, unconditional) bell to some key so that it  
can be invoked to test things.

[smime.p7s (application/pkcs7-signature, attachment)]

Message #195 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>,
        jasonspiro4 <at> gmail.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual	bellinstead
Date: Sun, 09 Nov 2008 21:07:29 -0500

> No, that's not the intent.  The intent is to make the visible bell the
> default.  To turn it off, you turn off visible-bell, which makes Emacs
> beep again, and then turn off the speakers.

Indeed.  A good reason to use visible-bell by default is that we have no
guarantee that the bell can actually be heard (e.g. I usually turn it
off because I usually consider that a computer should be as close to
silent as possible, except when I specifically ask otherwise (.e.g
listing to music or whatching a video)).

The other reason is that the beep can annoy other people than the user,
whereas the visible-bell is very unlikely to annoy other people than the
user herself.


        Stefan

Message #205 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
        "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: <1305 <at> debbugs.gnu.org>, <jasonspiro4 <at> gmail.com>,
        <bug-gnu-emacs <at> gnu.org>
Subject: RE: bug#1305: All code that currently beeps should use visual	bellinstead
Date: Sun, 9 Nov 2008 22:28:14 -0800

> > No, that's not the intent.  The intent is to make the 
> > visible bell the default.  To turn it off, you turn off
> > visible-bell, which makes Emacs
> > beep again, and then turn off the speakers.
> 
> Indeed.  A good reason to use visible-bell by default is that 
> we have no guarantee that the bell can actually be heard 

Indeed not. That the bell might not be heard is no reason to use the visible
bell. That just doesn't follow. This is not about guaranteeing that the user's
attention be drawn. This is not a fire alarm.

It is typically just a minor reminder, akin to the "Wrapped" indication in
Isearch that lets you know when you've reached the end of the buffer. And a
clear message like that is typically better and sufficient.

Many, if not most, uses of the bell are probably unnecessary. That's no reason
to replace them with a visible bell. Just get rid of the ones that are
inappropriate.

> (e.g. I usually turn it off because I usually consider that a computer
> should be as close to silent as possible, except when I
> specifically ask otherwise (.e.g listing to music or whatching a video)).

I feel the same and I do the same. However, that is *not* a good reason to use
visible-bell by default. I don't want to lose silence with no distraction only
to gain silence with visible annoyance by default. That's a bad trade.

If this is about the default behavior, and it is generally agreed that such
frequent distractions serve little purpose and are annoying, then they will
remain so if they are simply moved from sound to sight. That's running in
circles around the problem, not fixing it.

> The other reason is that the beep can annoy other people than 
> the user, whereas the visible-bell is very unlikely to annoy other 
> people than the user herself.

As Eli said, just get rid of gratuitous uses of the bell. It's likely that there
are plenty. And that will leave the more appropriate uses, if there are any.

Someone (Jason?) mentioned the bell when quitting and when an error is raised.
Those are very common uses that could no doubt be eliminated. Each error should
display a message anyway, and there is no need for a bell when you quit (C-q).
Getting rid of even just those occurrences would take care of much of the
annoyance.

Or if you prefer, leave those occurrences in, but add an option or two:
`bell-when-quit-flag' and `bell-when-error-flag' - with default values nil.
Perhaps let the values be `bell', `visible-bell', `bell+visible-bell', and nil.

Or some such. IOW, if you really must change something, reduce the current use
of the bell and visible bell. Please do not simply substitute visible-bell for
bell. That is a poor solution to the problem of frequent bell distraction.

Message #215 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Lennart Borgman" <lennart.borgman <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>,
        1305 <at> debbugs.gnu.org
Cc: "Eli Zaretskii" <eliz <at> gnu.org>, jasonspiro4 <at> gmail.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Mon, 10 Nov 2008 09:34:10 +0100

On Mon, Nov 10, 2008 at 3:07 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> No, that's not the intent.  The intent is to make the visible bell the
>> default.  To turn it off, you turn off visible-bell, which makes Emacs
>> beep again, and then turn off the speakers.
>
> Indeed.  A good reason to use visible-bell by default is that we have no
> guarantee that the bell can actually be heard (e.g. I usually turn it
> off because I usually consider that a computer should be as close to
> silent as possible, except when I specifically ask otherwise (.e.g
> listing to music or whatching a video)).
>
> The other reason is that the beep can annoy other people than the user,
> whereas the visible-bell is very unlikely to annoy other people than the
> user herself.

But there has been some messages telling that having it on by default
is good for visually impaired people.

Message #225 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Lennart Borgman" <lennart.borgman <at> gmail.com>
Cc: 1305 <at> debbugs.gnu.org, "Eli Zaretskii" <eliz <at> gnu.org>,
        jasonspiro4 <at> gmail.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Mon, 10 Nov 2008 10:22:47 -0500

> But there has been some messages telling that having it on by default
> is good for visually impaired people.

I don't buy it.  Visually impaired people have to deal with "turn visual
effects into auditive ones" anyway, so setting visible-bell is the least
of their problems.


        Stefan

Message #235 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Lennart Borgman" <lennart.borgman <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: 1305 <at> debbugs.gnu.org, "Eli Zaretskii" <eliz <at> gnu.org>,
        "Jason Spiro" <jasonspiro4 <at> gmail.com>
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Mon, 10 Nov 2008 17:58:34 +0100

On Mon, Nov 10, 2008 at 4:22 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> But there has been some messages telling that having it on by default
>> is good for visually impaired people.
>
> I don't buy it.  Visually impaired people have to deal with "turn visual
> effects into auditive ones" anyway, so setting visible-bell is the least
> of their problems.

I think the best would be if visually impaired people explained the
issue themselves. It might be different for different persons and
environments.

Message #240 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Xavier Maillard <xma <at> gnu.org>
To: Jason Spiro <jasonspiro4 <at> gmail.com>, 1305 <at> debbugs.gnu.org
Cc: control <at> debbugs.gnu.org, bug-submit-list <at> donarmstrong.com,
        bug-gnu-emacs <at> gnu.org, 1305 <at> debbugs.gnu.org,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
	instead
Date: Mon, 10 Nov 2008 22:25:14 +0100

   retitle 1305 All code that currently beeps should use visual bell instead
   thanks

That's way more appropriate to me.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Message #250 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Richard M. Stallman" <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 1305 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, bug-submit-list <at> donarmstrong.com, jasonspiro4 <at> gmail.com,
        bug-gnu-emacs <at> gnu.org, 1305 <at> debbugs.gnu.org,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use
	visual	bellinstead
Date: Mon, 10 Nov 2008 17:17:58 -0500

For changes like this, you should poll the users, with a poll
announced at least on info-gnu-emacs and help-gnu-emacs.

To get the most useful information in return, it is important to ask
them to state the reasons for their preference, rather than simply to
"vote".

Message #260 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason A. Spiro" <jasonspiro <at> gmail.com>
To: "Lennart Borgman" <lennart.borgman <at> gmail.com>
Cc: "Stefan Monnier" <monnier <at> iro.umontreal.ca>,
        1305 <at> debbugs.gnu.org, "Eli Zaretskii" <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Tue, 11 Nov 2008 13:38:44 -0500

2008/11/10 Lennart Borgman <lennart.borgman <at> gmail.com> wrote:
> I think the best would be if visually impaired people explained the
> issue themselves. It might be different for different persons and
> environments.

They explained already, both earlier in this thread and at
http://thread.gmane.org/gmane.emacs.emacspeak.general/1695 .

Message #265 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: rms <at> gnu.org
Cc: "Stefan Monnier" <monnier <at> iro.umontreal.ca>,
        1305 <at> debbugs.gnu.org, eliz <at> gnu.org,
        bug-submit-list <at> donarmstrong.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Tue, 11 Nov 2008 13:50:01 -0500

2008/11/10 Richard M. Stallman <rms <at> gnu.org> wrote:
> For changes like this, you should poll the users, with a poll
> announced at least on info-gnu-emacs and help-gnu-emacs.
>
> To get the most useful information in return, it is important to ask
> them to state the reasons for their preference, rather than simply to
> "vote".

We should poll for which change?  Surely removing beeping from the
trivial things like:

* quit (C-g), and
* moving the point off the end of the buffer, and
* failing isearches

should not require a poll.

Also, I think email polls are imperfect, since they drastically
increase list traffic.  IMO a better alternative is to create a page
on EmacsWiki and to ask people to add their Support or Oppose votes,
with explanations, to a new paragraph at the bottom of the page, or in
rebuttal to (and just below, but indented from) an existing paragraph.
 Then they should sign it with their name.  Kinda like
http://wikipedia.org/wiki/Wikipedia:Non-administrator_rollback/Poll
except that Support and Oppose votes will be interleaved with each
other.

Also, I think you should make it clear that you will not be bound by
the results, but that you will take them into consideration.

Message #275 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: "Xavier Maillard" <xma <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org,
        bug-submit-list <at> donarmstrong.com
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Tue, 11 Nov 2008 14:15:29 -0500

2008/11/9 Xavier Maillard <xma <at> gnu.org> wrote:
> What if the screen reader is not working correctly ? The visible
> bell could be used to check that something, at least, is working.

We could make a function like M-x ring-audible-bell (but you should
choose a better name than that) that would let blind / VI (visually
impaired) users know that Emacs is working.  Or we could design Emacs
so that when they launch Emacs using the command "emacspeak", then C-g
will always ring the audible bell.

This would be slightly more inconvenient for blind / VI users, but IMO
much better for fully sighted users.

Message #285 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Lennart Borgman" <lennart.borgman <at> gmail.com>
To: "Jason Spiro" <jasonspiro4 <at> gmail.com>, 1305 <at> debbugs.gnu.org
Cc: "Xavier Maillard" <xma <at> gnu.org>, bug-gnu-emacs <at> gnu.org,
        bug-submit-list <at> donarmstrong.com
Subject: Re: bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Date: Tue, 11 Nov 2008 21:05:21 +0100

On Tue, Nov 11, 2008 at 8:15 PM, Jason Spiro <jasonspiro4 <at> gmail.com> wrote:
> This would be slightly more inconvenient for blind / VI users, but IMO
> much better for fully sighted users.

If we think so then maybe we should consider that the impaired users
already have a bigger burden.

Message #295 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <1305 <at> debbugs.gnu.org>,
        "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
        "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: <jasonspiro4 <at> gmail.com>, <bug-gnu-emacs <at> gnu.org>
Subject: RE: bug#1305: All code that currently beeps should usevisual	bellinstead
Date: Tue, 11 Nov 2008 13:20:04 -0800

> As Eli said, just get rid of gratuitous uses of the bell. 
> It's likely that there are plenty. And that will leave the more
> appropriate uses, if there are any.
> 
> Someone (Jason?) mentioned the bell when quitting and when an 
> error is raised. Those are very common uses that could no doubt
> be eliminated. Each error should display a message anyway, and
> there is no need for a bell when you quit (C-q). Getting rid of
> even just those occurrences would take care of much of the
> annoyance.
> 
> Or if you prefer, leave those occurrences in, but add an 
> option or two: `bell-when-quit-flag' and `bell-when-error-flag'
> - with default values nil. Perhaps let the values be `bell',
> `visible-bell', `bell+visible-bell', and nil.

Let me draw your attention to this suggestion about having multiple ding levels:
http://thread.gmane.org/gmane.emacs.devel/74539/focus=74564

There were no replies to that suggestion, but perhaps it becomes more relevant
in the current context.

Message #305 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Richard M. Stallman" <rms <at> gnu.org>
To: "Jason Spiro" <jasonspiro4 <at> gmail.com>
Cc: monnier <at> iro.umontreal.ca, 1305 <at> debbugs.gnu.org, eliz <at> gnu.org,
        bug-submit-list <at> donarmstrong.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Tue, 11 Nov 2008 22:33:53 -0500

    We should poll for which change?  Surely removing beeping from the
    trivial things like:

    * quit (C-g), and
    * moving the point off the end of the buffer, and
    * failing isearches

    should not require a poll.

Sure it should.  You think it is an improvement, but I think the
opposite.  Let's see what the users think.

    Also, I think email polls are imperfect, since they drastically
    increase list traffic.

There may be a misunderstanding here.  Polls do not use this list.  We
create a special address for people to send their responses to, and
that address dumps everything into a file.

When the deadline comes, someone reads all the responses and analyzes
them.

			    IMO a better alternative is to create a page
    on EmacsWiki and to ask people to add their Support or Oppose votes,
    with explanations, to a new paragraph at the bottom of the page,

I think that is asking for trouble, as people may flame at each other
and may edit each other's text.

Message #315 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: rms <at> gnu.org
Cc: monnier <at> iro.umontreal.ca, 1305 <at> debbugs.gnu.org, eliz <at> gnu.org,
        bug-submit-list <at> donarmstrong.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Thu, 13 Nov 2008 02:41:29 -0500

2008/11/11 Richard M. Stallman <rms <at> gnu.org> wrote:

> > ...
> Sure it should.  You think it is an improvement, but I think the
> opposite.  Let's see what the users think.

Fair.

> > ...
> There may be a misunderstanding here.  Polls do not use this list.  We
> create a special address for people to send their responses to, and
> that address dumps everything into a file.
>
> When the deadline comes, someone reads all the responses and analyzes
> them.

Ah.  I stand corrected.

> > ...
> I think that is asking for trouble, as people may flame at each other
> and may edit each other's text.

Yes, there could be flaming.  And yes, editing each other's text is a
danger.  But the wiki's "history" command reduces this latter danger:
people can detect such tampering.

Still, rms, you have convinced me:  an email poll is better.  Dear
everybody:  Who will start the poll?

Message #325 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Tim Connors <tim.w.connors <at> gmail.com>
To: Jason Spiro <jasonspiro4 <at> gmail.com>
Cc: rms <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
        1305 <at> debbugs.gnu.org, eliz <at> gnu.org,
        bug-submit-list <at> donarmstrong.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual
 bellinstead
Date: Mon, 17 Nov 2008 18:32:38 +1100 (EST)

"Jason Spiro" <jasonspiro4 <at> gmail.com> wrote:
> 2008/11/10 Richard M. Stallman <rms <at> gnu.org> wrote:
>> For changes like this, you should poll the users, with a poll
>> announced at least on info-gnu-emacs and help-gnu-emacs.
>>
>> To get the most useful information in return, it is important to ask
>> them to state the reasons for their preference, rather than simply to
>> "vote".
>
> We should poll for which change?  Surely removing beeping from the
> trivial things like:
>
> * quit (C-g), and
> * moving the point off the end of the buffer, and
> * failing isearches
>
> should not require a poll.

See, I very much disagree that at least one of these is a "trivial" use,
which demonstrates that deciding not to ask for a poll because *you* think
something is obviously the case is a flawed proposition.

For the first year of the life of this laptop, the sound driver didn't
output beeps at all, which made editing in emacs very much more painful
(the latest ALSA release restores beeps for this chipset, yay).

I find visible-bell *way* too distracting, so use beeps (I can turn it
down and control its pitch, but I can't make reverse video any less of a
shock to the eyesight).  And I've lost count of the number of times I've
gone more than once around a buffer doing an isearch, because I failed to
hear the non-existant beep telling me I had already gone around once.  A
simple visual notification in the status area is not enough, because
almost by definition the entire screen is changing every isearch anyway,
so a few extra words saying "failing i-search" doesn't get noticed.

-- 
TimC
cat /kat/ n.  A furry keyboard cover

Message #335 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jason Spiro" <jasonspiro4 <at> gmail.com>
To: "Tim Connors" <tim.w.connors <at> gmail.com>
Cc: rms <at> gnu.org, "Stefan Monnier" <monnier <at> iro.umontreal.ca>,
        1305 <at> debbugs.gnu.org, eliz <at> gnu.org,
        bug-submit-list <at> donarmstrong.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Mon, 17 Nov 2008 02:37:59 -0500

2008/11/17 Tim Connors <tim.w.connors <at> gmail.com> wrote:
> [...]
> [...] I've lost count of the number of times I've
> gone more than once around a buffer doing an isearch, because I failed to
> hear the non-existant beep telling me I had already gone around once.  A
> simple visual notification in the status area is not enough, because
> almost by definition the entire screen is changing every isearch anyway,
> so a few extra words saying "failing i-search" doesn't get noticed.

Firefox's incremental search feature does it much better than Emacs.
When an incremental search is failing, it doesn't just add the word
"Failing" onscreen.  It also changes the search text entry field to
have a bright red background.  This attracts the eye to see that the
search is failing.  Should I file a bug to request that Emacs do the
same?

Message #345 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Sven Joachim <svenjoac <at> gmx.de>
To: Jason Spiro <jasonspiro4 <at> gmail.com>
Cc: 1305 <at> debbugs.gnu.org, "Tim Connors" <tim.w.connors <at> gmail.com>,
        rms <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Mon, 17 Nov 2008 09:01:16 +0100

On 2008-11-17 08:37 +0100, Jason Spiro wrote:

> 2008/11/17 Tim Connors <tim.w.connors <at> gmail.com> wrote:
>> [...]
>> [...] I've lost count of the number of times I've
>> gone more than once around a buffer doing an isearch, because I failed to
>> hear the non-existant beep telling me I had already gone around once.  A
>> simple visual notification in the status area is not enough, because
>> almost by definition the entire screen is changing every isearch anyway,
>> so a few extra words saying "failing i-search" doesn't get noticed.
>
> Firefox's incremental search feature does it much better than Emacs.
> When an incremental search is failing, it doesn't just add the word
> "Failing" onscreen.  It also changes the search text entry field to
> have a bright red background.  This attracts the eye to see that the
> search is failing.  Should I file a bug to request that Emacs do the
> same?

Emacs does it another way, one that in my opinion is even better: it
highlights just the part of the search that failed.  This is quite
convenient if you have already typed several extra characters before
noticing the search failure.

Note that this is not available in Emacs 22, but has been in the trunk
for about a year.

Sven

Message #350 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Sven Joachim'" <svenjoac <at> gmx.de>, <1305 <at> debbugs.gnu.org>,
        "'Jason Spiro'" <jasonspiro4 <at> gmail.com>
Cc: <rms <at> gnu.org>, "'Tim Connors'" <tim.w.connors <at> gmail.com>
Subject: RE: bug#1305: All code that currently beeps should use visualbellinstead
Date: Mon, 17 Nov 2008 00:19:10 -0800

> > Firefox's incremental search feature does it much better than Emacs.
> > When an incremental search is failing, it doesn't just add the word
> > "Failing" onscreen.  It also changes the search text entry field to
> > have a bright red background.  This attracts the eye to see that the
> > search is failing.  Should I file a bug to request that Emacs do the
> > same?
> 
> Emacs does it another way, one that in my opinion is even better: it
> highlights just the part of the search that failed.  This is quite
> convenient if you have already typed several extra characters before
> noticing the search failure.
> 
> Note that this is not available in Emacs 22, but has been in the trunk
> for about a year.

It's not only better in general, it's more appropriate for incremental search.
The increment of your search that is successful (matches) is not highlighted;
only the increment that is a mismatch is highlighted. The highlighting is added
and removed incrementally, as you type and delete characters.

Message #355 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Jason Spiro" <jasonspiro4 <at> gmail.com>
Cc: "Tim Connors" <tim.w.connors <at> gmail.com>, rms <at> gnu.org,
        1305 <at> debbugs.gnu.org, eliz <at> gnu.org,
        bug-submit-list <at> donarmstrong.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1305: All code that currently beeps should use visual bellinstead
Date: Mon, 17 Nov 2008 09:52:25 -0500

> Firefox's incremental search feature does it much better than Emacs.
> When an incremental search is failing, it doesn't just add the word
> "Failing" onscreen.  It also changes the search text entry field to
> have a bright red background.  This attracts the eye to see that the
> search is failing.  Should I file a bug to request that Emacs do the
> same?

I don't think it addresses Tim's problem that he simply doesn't see
(aka. look at) the echo area at all.

The bell is more noticeable (both the visual and the auditory one).


        Stefan

Message #367 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Giuseppe Scrivano <gscrivano <at> gnu.org>
Cc: Per Starbäck <per <at> starback.se>, emacs-devel <at> gnu.org,
        1305 <at> debbugs.gnu.org
Subject: Re: Emacs for new users
Date: Mon, 23 Nov 2009 15:49:26 -0500

Chong Yidong <cyd <at> stupidchicken.com> writes:

>>> * beeping is often disturbing and unexpected, in particular for
>>> scrolling past the beginning or end of the
>>>   buffer with the scroll wheel. (I agree. That's hardly an error.)
>>
>> yes, I agree with you, beeping is often disturbing.  You can disable it,
>> changing the value of visible-bell to t:

> This is bug#1305.  That discussion never came to a conclusion.

One complication, now that I recall, is that we really do want to signal
an error for beginning-of-buffer and end-of-buffer, so that keyboard
macros will terminate.

The problem is that we have no mechanism for telling Emacs not to ring
the bell for certain classes of errors.

But I'm not sure Emacs should even be in the bell-ringing business,
anyway; it's a barbaric practice, and an echo-area message IMHO
suffices.

Message #372 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Giuseppe Scrivano <gscrivano <at> gnu.org>,
        Per Starbäck
 <per <at> starback.se>,
        1305 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Beeping (was: Emacs for new users)
Date: Fri, 27 Nov 2009 00:35:27 +0200

>>>> * beeping is often disturbing and unexpected, in particular for
>>>> scrolling past the beginning or end of the
>>>>   buffer with the scroll wheel. (I agree. That's hardly an error.)
>>>
>>> yes, I agree with you, beeping is often disturbing.  You can disable it,
>>> changing the value of visible-bell to t:
>
>> This is bug#1305.  That discussion never came to a conclusion.
>
> One complication, now that I recall, is that we really do want to signal
> an error for beginning-of-buffer and end-of-buffer, so that keyboard
> macros will terminate.
>
> The problem is that we have no mechanism for telling Emacs not to ring
> the bell for certain classes of errors.

I suggest to implement this mechanism by adding a new symbol property,
e.g. `error-bell' by analogy with properties `error-message' and
`error-conditions', with possible values t, nil and `visible'.

And to put this property with the value nil on `beginning-of-buffer',
`end-of-buffer' and `keyboard-quit' - most annoying beeping commands.

> But I'm not sure Emacs should even be in the bell-ringing business,
> anyway; it's a barbaric practice, and an echo-area message IMHO
> suffices.

Yes, this practice comes from ancient times of beeping keyboards :-)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Message #377 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: Chong Yidong <cyd <at> stupidchicken.com>,
        Per Starbäck <per <at> starback.se>, emacs-devel <at> gnu.org,
        Giuseppe Scrivano <gscrivano <at> gnu.org>, 1305 <at> debbugs.gnu.org
Subject: Re: Beeping (was: Emacs for new users)
Date: Fri, 27 Nov 2009 00:12:49 +0100

On Thu, Nov 26, 2009 at 11:35 PM, Juri Linkov <juri <at> jurta.org> wrote:
>>
>> The problem is that we have no mechanism for telling Emacs not to ring
>> the bell for certain classes of errors.
>
> I suggest to implement this mechanism by adding a new symbol property,
> e.g. `error-bell' by analogy with properties `error-message' and
> `error-conditions', with possible values t, nil and `visible'.
>
> And to put this property with the value nil on `beginning-of-buffer',
> `end-of-buffer' and `keyboard-quit' - most annoying beeping commands.


Maybe the problem is a bit different. There is currently no dedicated
mechanism in Emacs to go to command level. Instead a lot of functions
throws an error when they want to go to command level.

Could we not implement something like (command-level) akin to (top-level)?

Message #382 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
        Per Starbäck <per <at> starback.se>,
        1305 <at> debbugs.gnu.org, Giuseppe Scrivano <gscrivano <at> gnu.org>,
        emacs-devel <at> gnu.org
Subject: Re: Beeping
Date: Thu, 26 Nov 2009 23:12:55 -0500

> Maybe the problem is a bit different. There is currently no dedicated
> mechanism in Emacs to go to command level. Instead a lot of functions
> throws an error when they want to go to command level.

> Could we not implement something like (command-level) akin to (top-level)?

I think there's a misunderstanding here.  Emacs usually tries to make
sure commands do *something*, because it' good to return feedback.
So when they don't, they often like to beep to indicate that they
couldn't do what they were asked to do.

I dislike the beep, so I always use the visual-bell instead.  I don't
think turning the bell into nothing at all is a good option.  I'd rather
try and address the reasons that prevent the visual-bell from being
the default.


        Stefan

Message #387 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
        Per Starbäck <per <at> starback.se>,
        1305 <at> debbugs.gnu.org, Giuseppe Scrivano <gscrivano <at> gnu.org>,
        emacs-devel <at> gnu.org
Subject: Re: Beeping
Date: Fri, 27 Nov 2009 07:48:07 +0100

2009/11/27 Stefan Monnier <monnier <at> iro.umontreal.ca>:
>> Maybe the problem is a bit different. There is currently no dedicated
>> mechanism in Emacs to go to command level. Instead a lot of functions
>> throws an error when they want to go to command level.
>
>> Could we not implement something like (command-level) akin to (top-level)?
>
> I think there's a misunderstanding here.  Emacs usually tries to make
> sure commands do *something*, because it' good to return feedback.
> So when they don't, they often like to beep to indicate that they
> couldn't do what they were asked to do.


As an example of what I mean look at what windmove-left does when
there is no window to the left. It then raises an error.

If debug-on-error is true I then get a chance to debug my behaviour. I
am not sure that makes sense.

The behaviour is different, but I think it should be similar to what
scroll-down/up does when it reaches the border. I think there should
be a unified behaviour. Making the visual bell default seems good, but
why not implement it as `command-level'?


> I dislike the beep, so I always use the visual-bell instead.  I don't
> think turning the bell into nothing at all is a good option.  I'd rather
> try and address the reasons that prevent the visual-bell from being
> the default.
>
>
>        Stefan
>

Message #392 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
        Per Starbäck <per <at> starback.se>,
        1305 <at> debbugs.gnu.org, Giuseppe Scrivano <gscrivano <at> gnu.org>,
        emacs-devel <at> gnu.org
Subject: Re: Beeping
Date: Fri, 27 Nov 2009 14:25:05 -0500

> As an example of what I mean look at what windmove-left does when
> there is no window to the left. It then raises an error.
> If debug-on-error is true I then get a chance to debug my behaviour. I
> am not sure that makes sense.

That's a problem between windmove and debug-ignored-errors.
BTW, I'd welcome a patch that introduces a new error `user-error' and
then changes calls to `error' where the error message is in
debug-ignored-errors to signal `user-error' instead.

> The behaviour is different, but I think it should be similar to what
> scroll-down/up does when it reaches the border. I think there should
> be a unified behaviour. Making the visual bell default seems good, but
> why not implement it as `command-level'?

That's already what "an error that's in debug-ignored-errors" does.


        Stefan

Message #397 received at 1305 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, Chong Yidong <cyd <at> stupidchicken.com>,
        Per Starbäck <per <at> starback.se>,
        1305 <at> debbugs.gnu.org, Giuseppe Scrivano <gscrivano <at> gnu.org>,
        emacs-devel <at> gnu.org
Subject: Re: Beeping
Date: Fri, 27 Nov 2009 21:25:59 +0100

2009/11/27 Stefan Monnier <monnier <at> iro.umontreal.ca>:
>> As an example of what I mean look at what windmove-left does when
>> there is no window to the left. It then raises an error.
>> If debug-on-error is true I then get a chance to debug my behaviour. I
>> am not sure that makes sense.
>
> That's a problem between windmove and debug-ignored-errors.
> BTW, I'd welcome a patch that introduces a new error `user-error' and
> then changes calls to `error' where the error message is in
> debug-ignored-errors to signal `user-error' instead.


You mean that debug-ignored-errors should just be '(user-error)?

Isn't there still a problem with condition-case then? Or perhaps it
could be tamed to pass on user-error?


>> The behaviour is different, but I think it should be similar to what
>> scroll-down/up does when it reaches the border. I think there should
>> be a unified behaviour. Making the visual bell default seems good, but
>> why not implement it as `command-level'?
>
> That's already what "an error that's in debug-ignored-errors" does.
>
>
>        Stefan
>

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org, jasonspiro4 <at> gmail.com,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 01:06:54 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> No, that's not the intent.  The intent is to make the visible bell the
>> default.  To turn it off, you turn off visible-bell, which makes Emacs
>> beep again, and then turn off the speakers.
>
> Indeed.  A good reason to use visible-bell by default is that we have no
> guarantee that the bell can actually be heard (e.g. I usually turn it
> off because I usually consider that a computer should be as close to
> silent as possible, except when I specifically ask otherwise (.e.g
> listing to music or whatching a video)).
>
> The other reason is that the beep can annoy other people than the user,
> whereas the visible-bell is very unlikely to annoy other people than the
> user herself.

(That was 12 years ago.)

So how about setting visible-bell to t by default in Emacs 28?  This
behavior was called "barbaric" by Chong Yidong in 2008, and the
situation hasn't improved since.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 drew.adams <at> oracle.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 10:03:43 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sat, 17 Apr 2021 01:06:54 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>, 
> 	jasonspiro4 <at> gmail.com
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> So how about setting visible-bell to t by default in Emacs 28?

What does visible-bell do on your system? is it prominently visible?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 13:54:06 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> So how about setting visible-bell to t by default in Emacs 28?  This
> behavior was called "barbaric" by Chong Yidong in 2008, and the
> situation hasn't improved since.

I think that sounds like a good idea, but does visible-bell look nice on
all systems, or are there major differences?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 12:31:27 +0000

[Message part 1 (text/plain, inline)]

>> So how about setting visible-bell to t by default in Emacs 28?  This 
>> behavior was called "barbaric" by Chong Yidong in 2008, and the 
>> situation hasn't improved since.
>
> I think that sounds like a good idea, but does visible-bell look nice on 
> all systems, or are there major differences?
>

I attach two screenshots, one on Debian GNU/Linux, the other one on macOS.

IMO, the default behavior on GNU/Linux (inverting video on the first and 
last line of the frame) is horrible (but perhaps less so than an actual 
bell), and the default behavior on macOS is too intrusive (but again 
perhaps less so than an actual bell).

Perhaps a nicer way to do this is possible, e.g. make the background of 
the minibuffer (which is what the user is invited to look at) yellow or 
red (unless it's already yellow or red).

[debian.png (image/png, attachment)]

[macos.png (image/png, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, 1305 <at> debbugs.gnu.org, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 15:39:54 +0300

> Date: Sat, 17 Apr 2021 12:31:27 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
>  Stefan Kangas <stefan <at> marxist.se>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> 
> IMO, the default behavior on GNU/Linux (inverting video on the first and 
> last line of the frame) is horrible (but perhaps less so than an actual 
> bell), and the default behavior on macOS is too intrusive (but again 
> perhaps less so than an actual bell).

On MS-Windows, we use a system API that flashes the caption bar of the
selected-frame's window.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 stefan <at> marxist.se, jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 14:55:03 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> IMO, the default behavior on GNU/Linux (inverting video on the first and 
>> last line of the frame) is horrible (but perhaps less so than an actual 
>> bell),

Hm...  when I try this on Debian/bullseye, it inverts the video on the
two first lines in the frame.  But I seem to recall it working the way
you describe, so perhaps there's differences between various
toolkits/libraries used by Emacs in this area?

>> and the default behavior on macOS is too intrusive (but again 
>> perhaps less so than an actual bell).
>
> On MS-Windows, we use a system API that flashes the caption bar of the
> selected-frame's window.

Then it sounds like visible-bell should be visible enough on all the
three major systems we support.

However, I just noticed that an "emacs -Q" doesn't beep at all on this
machine -- because I've switched off all "alert" beeps in the OS
interface.  So `C-g' just says "Quit" in the echo area, and nothing
else.

So in this instance, defaulting `visible-bell' to "on" would make `C-g'
more intrusive/obnoxious than previously...  which is the opposite
effect than what was originally discussed in this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 08:07:35 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> However, I just noticed that an "emacs -Q" doesn't beep at all on this
> machine -- because I've switched off all "alert" beeps in the OS
> interface.  So `C-g' just says "Quit" in the echo area, and nothing
> else.

What machine is that?

> So in this instance, defaulting `visible-bell' to "on" would make `C-g'
> more intrusive/obnoxious than previously...  which is the opposite
> effect than what was originally discussed in this bug report.

Can anything be done about that, though?

(I guess to turn it off completely you would be expected to set
`ring-bell-function' to #'ignore and visual-bell to nil.)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 15:13:51 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> However, I just noticed that an "emacs -Q" doesn't beep at all on this
>> machine -- because I've switched off all "alert" beeps in the OS
>> interface.  So `C-g' just says "Quit" in the echo area, and nothing
>> else.
>
> What machine is that?

It's a Debian/bullseye laptop with Gnome Shell -- so I guess it's a
Gnome Shell setting?  (The first thing I do with any machine is switch
off any "alert" beeps.)

>> So in this instance, defaulting `visible-bell' to "on" would make `C-g'
>> more intrusive/obnoxious than previously...  which is the opposite
>> effect than what was originally discussed in this bug report.
>
> Can anything be done about that, though?

I think this might point toward not doing anything about the default --
people who don't like beeps will switch them off on the OS level.  That
is, flipping the default will make `C-g' more intrusive for people
who've already made a decision to ignore beeps.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>,
 "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 "stefan <at> marxist.se" <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Sat, 17 Apr 2021 13:16:25 +0000

> >> IMO, the default behavior on GNU/Linux (inverting video on the first and
> >> last line of the frame) is horrible (but perhaps less so than an actual
> >> bell),
> 
> Hm...  when I try this on Debian/bullseye, it inverts the video on the
> two first lines in the frame.  But I seem to recall it working the way
> you describe, so perhaps there's differences between various
> toolkits/libraries used by Emacs in this area?
> 
> >> and the default behavior on macOS is too intrusive (but again
> >> perhaps less so than an actual bell).
> >
> > On MS-Windows, we use a system API that flashes the caption bar of the
> > selected-frame's window.
> 
> Then it sounds like visible-bell should be visible enough on all the
> three major systems we support.
> 
> However, I just noticed that an "emacs -Q" doesn't beep at all on this
> machine -- because I've switched off all "alert" beeps in the OS
> interface.  So `C-g' just says "Quit" in the echo area, and nothing
> else.
> 
> So in this instance, defaulting `visible-bell' to "on" would make `C-g'
> more intrusive/obnoxious than previously...  which is the opposite
> effect than what was originally discussed in this bug report.

Just as plain `ding' can be annoying for some
users, so can this or that kind of visible
indication.

It would be good if, at least on some systems
and preferably on all, some degree of user
customization were available.  (Yes, I know that
`visible-bell' already offers some customization.)

One possibility of a customization choice could
be a notification in the mode-line - just one
example.

For one way to do that, see the tiny library
`echo-bell.el' (initial code from Miles Bader).
It offers a minor mode, and options to define
the kind of mode-line indication.

https://www.emacswiki.org/emacs/download/echo-bell.el

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 08:32:14 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> It's a Debian/bullseye laptop with Gnome Shell -- so I guess it's a
> Gnome Shell setting?  (The first thing I do with any machine is switch
> off any "alert" beeps.)

Oh, I don't use any of that stuff.  I have my own custom .xinitrc
instead with as little stuff as possible in it.  So I'm not sure how I
could even set such a setting.  I suppose it's some gconf stuff taking
place behind the scenes...?

Searching online shows this might be it:

sudo su gdm -c "gconftool-2 --set /desktop/gnome/sound/event_sounds
--type bool false"

But I don't have gconftool-2 so my Debian bullseye machine is probably
missing some prerequisites.

> I think this might point toward not doing anything about the default --
> people who don't like beeps will switch them off on the OS level.  That
> is, flipping the default will make `C-g' more intrusive for people
> who've already made a decision to ignore beeps.

It is my understanding that Emacs is unusual in using the system bell
though.  It would be better to avoid it completely, even when that
setting is on.

Would it perhaps make sense to make visual-bell support that setting
instead?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 15:39:04 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Oh, I don't use any of that stuff.  I have my own custom .xinitrc
> instead with as little stuff as possible in it.  So I'm not sure how I
> could even set such a setting.  I suppose it's some gconf stuff taking
> place behind the scenes...?

I poked around, and it's "Settings -> Sound -> System Sounds" in Gnome
Shell that I had switched to a volume of zero.  

> It is my understanding that Emacs is unusual in using the system bell
> though.  It would be better to avoid it completely, even when that
> setting is on.

I turned the volume up, and saying "lTAB" in the shell (in a Console
window) then beeped audibly.  So the default here is to make sounds.
And I just checked the same on my Apple laptop -- the shell there also
beeps a lot.

(I haven't checked whether any other programs beep at me.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: gregory <at> heytings.org, 1305 <at> debbugs.gnu.org, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 17:05:17 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Gregory Heytings <gregory <at> heytings.org>,
>   jasonspiro4 <at> gmail.com,  1305 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Sat, 17 Apr 2021 15:39:04 +0200
> 
> > It is my understanding that Emacs is unusual in using the system bell
> > though.  It would be better to avoid it completely, even when that
> > setting is on.
> 
> I turned the volume up, and saying "lTAB" in the shell (in a Console
> window) then beeped audibly.  So the default here is to make sounds.
> And I just checked the same on my Apple laptop -- the shell there also
> beeps a lot.

That is my experience as well: programs make sounds nowadays all the
time, and one needs to customize the system to make them shut up.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 09:08:10 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I poked around, and it's "Settings -> Sound -> System Sounds" in Gnome
> Shell that I had switched to a volume of zero.

Does that have an option to use a visual bell instead?

>> It is my understanding that Emacs is unusual in using the system bell
>> though.  It would be better to avoid it completely, even when that
>> setting is on.
>
> I turned the volume up, and saying "lTAB" in the shell (in a Console
> window) then beeped audibly.  So the default here is to make sounds.
> And I just checked the same on my Apple laptop -- the shell there also
> beeps a lot.

What is less clear to me is why Emacs should mimic the behavior of
terminal emulators of 1980s era terminals that mimicked 1970s era
terminals.  :-)

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 stefan <at> marxist.se, jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 19:59:13 +0300

On 17.04.2021 15:55, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> IMO, the default behavior on GNU/Linux (inverting video on the first and
>>> last line of the frame) is horrible (but perhaps less so than an actual
>>> bell),
> 
> Hm...  when I try this on Debian/bullseye, it inverts the video on the
> two first lines in the frame.  But I seem to recall it working the way
> you describe, so perhaps there's differences between various
> toolkits/libraries used by Emacs in this area?

Same here. It's either GTK3 build, or its HiDPI support (if you also 
have a HiDPI screen).

>>> and the default behavior on macOS is too intrusive (but again
>>> perhaps less so than an actual bell).
>>
>> On MS-Windows, we use a system API that flashes the caption bar of the
>> selected-frame's window.
> 
> Then it sounds like visible-bell should be visible enough on all the
> three major systems we support.

From what I see, visible-bell does nothing in 'emacs -nw'.

Not sure how easy that would be to fix.

> However, I just noticed that an "emacs -Q" doesn't beep at all on this
> machine -- because I've switched off all "alert" beeps in the OS
> interface.  So `C-g' just says "Quit" in the echo area, and nothing
> else.
> 
> So in this instance, defaulting `visible-bell' to "on" would make `C-g'
> more intrusive/obnoxious than previously...  which is the opposite
> effect than what was originally discussed in this bug report.

Well, we probably do want it to have some effect in general, unless the 
user has customized is off in some way or another.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 20:01:51 +0300

On 17.04.2021 16:13, Lars Ingebrigtsen wrote:
>>> So in this instance, defaulting `visible-bell' to "on" would make `C-g'
>>> more intrusive/obnoxious than previously...  which is the opposite
>>> effect than what was originally discussed in this bug report.
>> Can anything be done about that, though?
> I think this might point toward not doing anything about the default --
> people who don't like beeps will switch them off on the OS level.  That
> is, flipping the default will make `C-g' more intrusive for people
> who've already made a decision to ignore beeps.

Let's not venture into the xkcd.com/1172 territory, please.

What we should be asking is which one is the better default.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 20:17:35 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> It's a Debian/bullseye laptop with Gnome Shell -- so I guess it's a
>> Gnome Shell setting?  (The first thing I do with any machine is switch
>> off any "alert" beeps.)
>
> Oh, I don't use any of that stuff.  I have my own custom .xinitrc
> instead with as little stuff as possible in it.  So I'm not sure how I
> could even set such a setting.  I suppose it's some gconf stuff taking
> place behind the scenes...?
>
> Searching online shows this might be it:
>
> sudo su gdm -c "gconftool-2 --set /desktop/gnome/sound/event_sounds
> --type bool false"
>
> But I don't have gconftool-2 so my Debian bullseye machine is probably
> missing some prerequisites.

FWIW, in my ~/.xsessionrc I have:

  [ -x "$(command -v xset)" ] && xset b off

And for readline in general, in /etc/inputrc I have:

  # do not bell on tab-completion
  set bell-style none

I think I added this last one to silence loud beeps in the virtual
terminal.

But then I don't use a full desktop environment like GNOME, so maybe
these settings aren't as relevant or comprehensive there.

-- 
Basil

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 20:59:52 +0000

>>> So in this instance, defaulting `visible-bell' to "on" would make 
>>> `C-g' more intrusive/obnoxious than previously...  which is the 
>>> opposite effect than what was originally discussed in this bug report.
>>
>> Can anything be done about that, though?
>
> I think this might point toward not doing anything about the default -- 
> people who don't like beeps will switch them off on the OS level.  That 
> is, flipping the default will make `C-g' more intrusive for people 
> who've already made a decision to ignore beeps.
>

Note that for GNU/Linux users who use a more exotic window manager instead 
of Gnome or KDE, it's the opposite: they have to make an active decision 
to hear beeps.  IOW, they will not hear any beep unless they configure 
their computer to do so.

I checked on macOS, and the only apps (at least, the only apps among the 
ones I use) that repeatedly beep are the terminal and Emacs.  Other apps 
only beep when you do something "wrong", that is, when they cannot do what 
you want (for example when you ask the program to paste something when 
there is nothing to paste), or when they open an important dialog.  The 
terminal also beeps when it cannot do what you want (for example when you 
press TAB and it cannot complete the current input).  In comparison, Emacs 
beeps a lot.

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

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 17:09:40 -0400

Gregory Heytings <gregory <at> heytings.org> writes:

>>>> So in this instance, defaulting `visible-bell' to "on" would make
>>>> `C-g' more intrusive/obnoxious than previously...  which is the
>>>> opposite effect than what was originally discussed in this bug
>>>> report.
>>>
>>> Can anything be done about that, though?
>>
>> I think this might point toward not doing anything about the default
>> -- people who don't like beeps will switch them off on the OS level.
>> That is, flipping the default will make `C-g' more intrusive for
>> people who've already made a decision to ignore beeps.
>>
>
> Note that for GNU/Linux users who use a more exotic window manager
> instead of Gnome or KDE, it's the opposite: they have to make an
> active decision to hear beeps.  IOW, they will not hear any beep
> unless they configure their computer to do so.
>
> I checked on macOS, and the only apps (at least, the only apps among
> the ones I use) that repeatedly beep are the terminal and Emacs.
> Other apps only beep when you do something "wrong", that is, when they
> cannot do what you want (for example when you ask the program to paste
> something when there is nothing to paste), or when they open an
> important dialog.  The terminal also beeps when it cannot do what you
> want (for example when you press TAB and it cannot complete the
> current input).  In comparison, Emacs beeps a lot.

Really?  I find that, in general, Emacs only beeps when it cannot do
what I want (for example, C-n at EOB) or I cancel an operation (C-g or
ESC ESC ESC).  Under what other circumstances are you encountering
beeping?

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 21:17:08 +0000

>> I checked on macOS, and the only apps (at least, the only apps among 
>> the ones I use) that repeatedly beep are the terminal and Emacs. Other 
>> apps only beep when you do something "wrong", that is, when they cannot 
>> do what you want (for example when you ask the program to paste 
>> something when there is nothing to paste), or when they open an 
>> important dialog.  The terminal also beeps when it cannot do what you 
>> want (for example when you press TAB and it cannot complete the current 
>> input).  In comparison, Emacs beeps a lot.
>
> Really?  I find that, in general, Emacs only beeps when it cannot do 
> what I want (for example, C-n at EOB) or I cancel an operation (C-g or 
> ESC ESC ESC).  Under what other circumstances are you encountering 
> beeping?
>

For example, every time you press C-g, and every time you search for 
something that it cannot find.  When you press C-g Emacs does what you 
want, so why beep?  When you search for something that isn't there you 
already see that it isn't there, so why beep?

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

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Sat, 17 Apr 2021 17:52:18 -0400

Gregory Heytings <gregory <at> heytings.org> writes:

>>> I checked on macOS, and the only apps (at least, the only apps
>>> among the ones I use) that repeatedly beep are the terminal and
>>> Emacs. Other apps only beep when you do something "wrong", that is,
>>> when they cannot do what you want (for example when you ask the
>>> program to paste something when there is nothing to paste), or when
>>> they open an important dialog.  The terminal also beeps when it
>>> cannot do what you want (for example when you press TAB and it
>>> cannot complete the current input).  In comparison, Emacs beeps a
>>> lot.
>>
>> Really?  I find that, in general, Emacs only beeps when it cannot do
>> what I want (for example, C-n at EOB) or I cancel an operation (C-g
>> or ESC ESC ESC).  Under what other circumstances are you
>> encountering beeping?
>>
>
> For example, every time you press C-g, and every time you search for
> something that it cannot find.  When you press C-g Emacs does what you
> want, so why beep?  

You could make an argument for that.  Though ESC ESC ESC only beeps if
it canceled something.

> When you search for something that isn't there you already see that it
> isn't there, so why beep?

This one is easy.  It's so I know that it isn't there, that nothing was
found.  It's much easier to hear the beep than to realize visually that
it hasn't been found, and it is very useful to hear the beep before
search wraps around.  Moreover, I think this falls into the category you
called:

>>> when you do something "wrong", that is, when they cannot do what you
>>> want.

That said, I'm not going to argue about this very much.  I just wanted
to solicit an opinion.  Outside of possibly C-g, I don't see that Emacs
beeps any more than it should.  If the default is changed, I can change
it back on my end.

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sat, 17 Apr 2021 22:04:57 +0000

>
> That said, I'm not going to argue about this very much.
>

Me neither.  I was giving a feedback from the point of view of a user who 
disables all beeps, visual or not, and who knows he's not alone: 
Spacemacs, Doom Emacs and Prelude (and probably others, I did not check) 
all set ring-bell-function to nil.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Gregory Heytings <gregory <at> heytings.org>, Michael Welsh Duggan
 <mwd <at> md5i.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Sat, 17 Apr 2021 23:30:15 +0000

> I was giving a feedback from the point of view of a user who
> disables all beeps, visual or not, and who knows he's not alone:
> Spacemacs, Doom Emacs and Prelude (and probably others, I did not check)
> all set ring-bell-function to nil.

I too disable all audible beeps.  But I don't set
`ring-bell-function' to nil.  I set it to function
`echo-bell', which shows `echo-bell-string' in the
echo area for `echo-bell-delay' sec.  It's shown
at the far right of the echo area.

(I mistakenly wrote earlier (msg #424) that it's
shown in the mode-line.  I meant echo-area.)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, 1305 <at> debbugs.gnu.org, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 09:30:34 +0300

> Date: Sat, 17 Apr 2021 20:59:52 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
>  Stefan Kangas <stefan <at> marxist.se>, monnier <at> iro.umontreal.ca
> 
> I checked on macOS, and the only apps (at least, the only apps among the 
> ones I use) that repeatedly beep are the terminal and Emacs.  Other apps 
> only beep when you do something "wrong", that is, when they cannot do what 
> you want (for example when you ask the program to paste something when 
> there is nothing to paste), or when they open an important dialog.  The 
> terminal also beeps when it cannot do what you want (for example when you 
> press TAB and it cannot complete the current input).  In comparison, Emacs 
> beeps a lot.

Emacs beeps a lot if you do things that make it beep.  Like try to go
where no one has gone before.

By contrast, other apps beep when they see fit.  A MUA plays sounds
when a new email arrives; the desktop beeps when it has some
notification that it thinks you must see and act upon, etc. etc.

I don't see how Emacs is the odd one out here.

And we are bikeshedding again: the opinions are clearly divided, and
Emacs lets each one of us customize this feature as they see fit.  So
why is arguing about the default so important, when there's clearly no
consensus?  I say let's just close the issue as wontfix and move on.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 1305 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 12:38:03 +0200

Gregory Heytings <gregory <at> heytings.org> writes:

> Me neither.  I was giving a feedback from the point of view of a user
> who disables all beeps, visual or not, and who knows he's not alone:
> Spacemacs, Doom Emacs and Prelude (and probably others, I did not
> check) all set ring-bell-function to nil.

That's an interesting data point.  (But I assume you mean #'ignore?)

So perhaps we should instead discuss whether we should change the
default of `ring-bell-function', and leave `visible-bell' as is?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 12:41:01 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

>> I poked around, and it's "Settings -> Sound -> System Sounds" in Gnome
>> Shell that I had switched to a volume of zero.
>
> Does that have an option to use a visual bell instead?

Nope.  But you can choose between a range of different beeps.

> What is less clear to me is why Emacs should mimic the behavior of
> terminal emulators of 1980s era terminals that mimicked 1970s era
> terminals.  :-)

It probably shouldn't, but finding the least annoying change here is
unexpectedly non-trivial.

The visual-bell on Macos is pretty, but really intrusive.  If we want to
make the visual bell the default, we should perhaps change that first.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 1305 <at> debbugs.gnu.org, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 11:10:45 +0000

>
> Emacs beeps a lot if you do things that make it beep.  Like try to go 
> where no one has gone before.
>
> By contrast, other apps beep when they see fit.  A MUA plays sounds when 
> a new email arrives; the desktop beeps when it has some notification 
> that it thinks you must see and act upon, etc. etc.
>
> I don't see how Emacs is the odd one out here.
>

It just feels awkward by today's standards.

Emacs beeps when there is in fact no good reason to beep: whenever you 
type C-g, when isearch doesn't find a match, when you press C-p at BOB or 
C-n at EOB, when you press C-v or M-v too much (which can in fact be, for 
a short enough buffer: whenever you type C-v or M-v), when you press a 
self-inserting key in a read-only buffer, and so forth.  There is no good 
reason to beep, because (1) the echo area already contains an explanation 
about what happened, and (2) the error is not important enough to call the 
user's attention, nothing serious can happen if the user doesn't see it. 
In such cases flashing the echo area would be more than enough.

By contrast, Emacs doesn't beep when there would perhaps be a good reason 
to beep, for example when yes-or-no-p/y-or-n-p are called.

>
> And we are bikeshedding again: the opinions are clearly divided, and 
> Emacs lets each one of us customize this feature as they see fit.  So 
> why is arguing about the default so important, when there's clearly no 
> consensus?
>

We are discussing what a better default could be; in another thread the 
discussion is about a better default for the 'match' face.  Is discussing 
the default UX useless because everyone can customize everything?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, 1305 <at> debbugs.gnu.org, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 14:38:02 +0300

> Date: Sun, 18 Apr 2021 11:10:45 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org, 
>     stefan <at> marxist.se, monnier <at> iro.umontreal.ca
> 
> > I don't see how Emacs is the odd one out here.
> 
> It just feels awkward by today's standards.

I don't share that opinion, but maybe we have different ideas of
today's standards.

> > And we are bikeshedding again: the opinions are clearly divided, and 
> > Emacs lets each one of us customize this feature as they see fit.  So 
> > why is arguing about the default so important, when there's clearly no 
> > consensus?
> 
> We are discussing what a better default could be; in another thread the 
> discussion is about a better default for the 'match' face.  Is discussing 
> the default UX useless because everyone can customize everything?

That's not what I said.  Discussing changes in the defaults is useful
when there's consensus and/or when customization is tricky.  Neither
of those are true in this case.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 07:22:03 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> The visual-bell on Macos is pretty, but really intrusive.  If we want to
> make the visual bell the default, we should perhaps change that first.

True, it is *really* intrusive.  And it hides a large part of your
buffer text too, which is highly annoying to me.  So I guess we should
do something about it first, yes.

So how can we make it less intrusive?  Would it be enough to make it
smaller, or move its position or something?  For example, if it was a
bit smaller and in the top right?  I would probably also decrease its
duration to around three thirds or even half of what it is now.

Or do we need a complete rethinking of this?  Perhaps there is some
other software that we can steal some good ideas from?  (And if we can
come up with something very good, perhaps we will want to do the same on
GNU/Linux.)

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Gregory Heytings <gregory <at> heytings.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 1305 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 07:22:18 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So perhaps we should instead discuss whether we should change the
> default of `ring-bell-function', and leave `visible-bell' as is?

I'm personally fine with that, but I suspect it would be controversial
as it would leave us with no way of beeping (visual or otherwise).

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 14:36:55 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> I'm personally fine with that, but I suspect it would be controversial
> as it would leave us with no way of beeping (visual or otherwise).

You get a message in the echo area...

As somebody else noted earlier, if you have visible-bell on, but use
"-nw", that's the only notification you get -- there's no visible bell
on the console.  So you could say that there's some precedence for using
just the echo area as the only notification mechanism (beyond apparently
all the popular Emacs distributions doing exactly that).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 08:10:08 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> I'm personally fine with that, but I suspect it would be controversial
>> as it would leave us with no way of beeping (visual or otherwise).
>
> You get a message in the echo area...

Not for `ding' though, e.g.:

    (progn
      (setq ring-bell-function #'ignore)
      (defun foo () (interactive) (ding)))

    M-x foo RET

So if we make that change, perhaps we should make `ding' obsolete in
favour of `user-error'.

> As somebody else noted earlier, if you have visible-bell on, but use
> "-nw", that's the only notification you get -- there's no visible bell
> on the console.  So you could say that there's some precedence for using
> just the echo area as the only notification mechanism (beyond apparently
> all the popular Emacs distributions doing exactly that).

True.  You have my vote, FWIW.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 08:15:54 -0500

Stefan Kangas <stefan <at> marxist.se> writes:

> So if we make that change, perhaps we should make `ding' obsolete in
> favour of `user-error'.

Or maybe not: `ding' cancels keyboard macros, right?  So there would
still be some use for it, if you want to cancel a keyboard macro but do
nothing visible in interactive use.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 1305 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 13:32:48 +0000

>
> Or do we need a complete rethinking of this?  Perhaps there is some 
> other software that we can steal some good ideas from?
>

FWIW, what I would do for the default is to leave visible-bell to nil, and 
to use ring-bell-function to temporarily turn the cursor color to red and 
to put the message in the echo area on a yellow background.  Of course 
these colors would be configurable.  This would work on all platforms, and 
isn't too intrusive; at least it's less intrusive than the current 
defaults with visible-bell nil or t on GNU/Linux and macOS.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:06:31 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 18 Apr 2021 14:36:55 +0200
> Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
>  Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
>  jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
> 
> As somebody else noted earlier, if you have visible-bell on, but use
> "-nw", that's the only notification you get -- there's no visible bell
> on the console.

Is that really true?  I see in the code that we do support
visible-bell on TTY frames if terminfo says the terminal is capable of
doing that, see term.c:tty_ring_bell.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 17:11:21 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Is that really true?  I see in the code that we do support
> visible-bell on TTY frames if terminfo says the terminal is capable of
> doing that, see term.c:tty_ring_bell.

I tried in both Console and xterm on this Debian/bullseye system, and
`C-g' doesn't do anything visible to me with `visible-bell' switched
on...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Gregory Heytings <gregory <at> heytings.org>
Cc: "larsi <at> gnus.org" <larsi <at> gnus.org>,
 "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 "stefan <at> marxist.se" <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Sun, 18 Apr 2021 15:14:18 +0000

> the opinions are clearly divided, and Emacs lets each
> one of us customize this feature as they see fit.  So
> why is arguing about the default so important, when
> there's clearly no consensus?  I say let's just close
> the issue as wontfix and move on.

+1.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:18:37 +0300

On 18.04.2021 18:06, Eli Zaretskii wrote:
>> As somebody else noted earlier, if you have visible-bell on, but use
>> "-nw", that's the only notification you get -- there's no visible bell
>> on the console.
> Is that really true?  I see in the code that we do support
> visible-bell on TTY frames if terminfo says the terminal is capable of
> doing that, see term.c:tty_ring_bell.

I've tried it in gnome-terminal and terminator.

Could be just a bug, though.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 17:22:11 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

>> As somebody else noted earlier, if you have visible-bell on, but use
>> "-nw", that's the only notification you get -- there's no visible bell
>> on the console.  So you could say that there's some precedence for using
>> just the echo area as the only notification mechanism (beyond apparently
>> all the popular Emacs distributions doing exactly that).
>
> True.  You have my vote, FWIW.

I'm not really advocating anything in particular here.  :-)  I'm just
trying to get a clearer overview of what the current situation really
is, and what options are available to us.

I think it's clear that we can't just flip `visible-bell' on -- that
will be annoying to a substantial number of people (who currently have
neither beeping nor a visible bell).

I think, perhaps, introducing a new visible bell (across all
significant system), that's considerably less intrusive than the ones we
have today on GNU/Linux and Macos, might be an option.  And then
defaulting to using that.

Gregory suggested blinking the cursor in a different colour -- perhaps?
Or something like the Macos blinker -- but as you suggest, a lot smaller
and of a much shorter duration.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 1305 <at> debbugs.gnu.org,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 17:23:02 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Or do we need a complete rethinking of this?  Perhaps there is some
> other software that we can steal some good ideas from?  (And if we can
> come up with something very good, perhaps we will want to do the same on
> GNU/Linux.)

That's a good idea.  What does (for instance) Libreoffice or Excel do to
signal a user error or "end of search" and stuff like that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:23:57 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  mwd <at> md5i.com,  gregory <at> heytings.org,
>   1305 <at> debbugs.gnu.org,  jasonspiro4 <at> gmail.com,  monnier <at> iro.umontreal.ca
> Date: Sun, 18 Apr 2021 17:11:21 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Is that really true?  I see in the code that we do support
> > visible-bell on TTY frames if terminfo says the terminal is capable of
> > doing that, see term.c:tty_ring_bell.
> 
> I tried in both Console and xterm on this Debian/bullseye system, and
> `C-g' doesn't do anything visible to me with `visible-bell' switched
> on...

If you put a breakpoint inside tty_ring_bell, do you see that
tty->TS_visible_bell is non-NULL or not?  If it's non-NULL, perhaps
the terminal emulator has that disabled somehow?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:26:10 +0300

On 18.04.2021 15:36, Lars Ingebrigtsen wrote:
> So you could say that there's some precedence for using
> just the echo area as the only notification mechanism (beyond apparently
> all the popular Emacs distributions doing exactly that).

Not really all of them. Here's what the distributions do:

Prelude and Spacemacs:

  (setq ring-bell-function 'ignore)

better-defaults:

  (setq visible-bell t)

Doom:

  (setq ring-bell-function #'doom-themes-visual-bell-fn
        visible-bell t)

  (defface doom-visual-bell '((t (:inherit error)))
    "Face to use for the mode-line when `doom-themes-visual-bell-config'
  is used."
    :group 'doom-themes)

  ;;;###autoload
  (defun doom-themes-visual-bell-fn ()
    "Blink the mode-line red briefly. Set `ring-bell-function' to this
  to use it."
    (let ((doom-themes--bell-cookie (face-remap-add-relative 'mode-line 
'doom-visual-bell)))
      (force-mode-line-update)
      (run-with-timer 0.15 nil
                      (lambda (cookie buf)
                        (with-current-buffer buf
                          (face-remap-remove-relative cookie)
                          (force-mode-line-update)))
                      doom-themes--bell-cookie
                      (current-buffer))))

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>,
 "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Sun, 18 Apr 2021 15:27:53 +0000

> > I'm personally fine with that, but I suspect it would be controversial
> > as it would leave us with no way of beeping (visual or otherwise).
> 
> You get a message in the echo area...
> 
> As somebody else noted earlier, if you have visible-bell on, but use
> "-nw", that's the only notification you get -- there's no visible bell
> on the console.  So you could say that there's some precedence for using
> just the echo area as the only notification mechanism (beyond apparently
> all the popular Emacs distributions doing exactly that).

`echo-bell'...

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 11:28:22 -0400

> I think, perhaps, introducing a new visible bell (across all
> significant system), that's considerably less intrusive than the ones we
> have today on GNU/Linux and Macos, might be an option.  And then
> defaulting to using that.

FWIW, I don't see what's "intrusive" about the "blink top and bottom lines of
the selected frame" which I currently see in GNU/Linux.

It may not be slick but it does the job and I don't find it intrusive.
Of course, I'm biased (I've used it for too many years), but it's
clearly less intrusive than the non-visual bell.



        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:35:54 +0300

> Date: Sun, 18 Apr 2021 18:23:57 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se, gregory <at> heytings.org,
>  jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
> 
> If you put a breakpoint inside tty_ring_bell, do you see that
> tty->TS_visible_bell is non-NULL or not?  If it's non-NULL, perhaps
> the terminal emulator has that disabled somehow?

For example, PuTTY lets you customize what the bell does, so perhaps
xterm and other emulators do as well?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Sun, 18 Apr 2021 15:37:51 +0000

>
> Doom:
>
>  (setq ring-bell-function #'doom-themes-visual-bell-fn
>        visible-bell t)
>

That's not what I see at 
https://github.com/hlissner/doom-emacs/blob/develop/core/core-ui.el :

(setq uniquify-buffer-name-style 'forward
      ;; no beeping or blinking please
      ring-bell-function #'ignore
      visible-bell nil)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 17:38:52 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> FWIW, I don't see what's "intrusive" about the "blink top and bottom lines of
> the selected frame" which I currently see in GNU/Linux.

In this Emacs, it blinks the two topmost lines.  Which may be a bug?

> It may not be slick but it does the job and I don't find it intrusive.
> Of course, I'm biased (I've used it for too many years), but it's
> clearly less intrusive than the non-visual bell.

It's more intrusive than what many people are using -- which is neither
an audible nor a visible bell, but just the echo area saying "Quit" when
you hit `C-g' (etc).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 15:42:03 +0000

>> Or do we need a complete rethinking of this?  Perhaps there is some 
>> other software that we can steal some good ideas from?  (And if we can 
>> come up with something very good, perhaps we will want to do the same 
>> on GNU/Linux.)
>
> That's a good idea.  What does (for instance) Libreoffice or Excel do to 
> signal a user error or "end of search" and stuff like that?
>

LibreOffice does very little: when the string is not found at all in the 
document it turns red and a "Search key not found" message is displayed at 
the end of the search bar; when you reach the last occurrence a "Reached 
the end of the document" is displayed in the search bar and the search 
wraps silently.  For other errors, LibreOffice does even less, for example 
if you paste and there is nothing to paste, nothing happens, and that's 
all.

For Microsoft Office, I don't know, but from what I remember the error 
handling was similar.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:07:25 +0200

On Apr 18 2021, Lars Ingebrigtsen wrote:

> I tried in both Console and xterm on this Debian/bullseye system, and
> `C-g' doesn't do anything visible to me with `visible-bell' switched
> on...

What does tput flash do?

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: mwd <at> md5i.com, gregory <at> heytings.org, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 11:12:00 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I tried in both Console and xterm on this Debian/bullseye system, and
> `C-g' doesn't do anything visible to me with `visible-bell' switched
> on...

Did you try this in "xterm -vb"?  I get flashing here when I use that
(my X Resources disables it so I need to use that flag).

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, jasonspiro4 <at> gmail.com,
 gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:20:18 +0200

On Apr 18 2021, Stefan Kangas wrote:

> Did you try this in "xterm -vb"?  I get flashing here when I use that
> (my X Resources disables it so I need to use that flag).

The visual bell (tput flash) should be independent of -vb (which
controls the effect of ^G).

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

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

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> Doom:
>
>    (setq ring-bell-function #'doom-themes-visual-bell-fn
>          visible-bell t)
>
>    (defface doom-visual-bell '((t (:inherit error)))
>      "Face to use for the mode-line when `doom-themes-visual-bell-config'
>    is used."
>      :group 'doom-themes)
>
>    ;;;###autoload
>    (defun doom-themes-visual-bell-fn ()
>      "Blink the mode-line red briefly. Set `ring-bell-function' to this
>    to use it."

The docstring isn't clear what "blinking" means, but they briefly set
the *foreground* color to red (or whatever color `error' is configured
to be).

I think it's a neat idea.  It would be interesting to know how well it
works with third-party mode line (e.g. "powerline") packages.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca,
 Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 16:38:56 +0000

>
> The docstring isn't clear what "blinking" means, but they briefly set 
> the *foreground* color to red (or whatever color `error' is configured 
> to be).
>

The foreground of the whole buffer?  IMO that's very intrusive for a 
default.  Also, this isn't the default Doom behavior, I just checked and 
doom-visual-bell is an optional extension.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 1305 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 17:02:35 +0000

[Message part 1 (text/plain, inline)]

>
> I think, perhaps, introducing a new visible bell (across all significant 
> system), that's considerably less intrusive than the ones we have today 
> on GNU/Linux and Macos, might be an option.  And then defaulting to 
> using that.
>
> Gregory suggested blinking the cursor in a different colour -- perhaps?
>

I attach a POC of what I have in mind.

[visible-bell.el (text/plain, attachment)]

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 jasonspiro4 <at> gmail.com, 1305 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 20:05:06 +0300

On 18.04.2021 19:38, Gregory Heytings wrote:
> 
>>
>> The docstring isn't clear what "blinking" means, but they briefly set 
>> the *foreground* color to red (or whatever color `error' is configured 
>> to be).
>>
> 
> The foreground of the whole buffer?

For the mode-line.

> Also, this isn't the default Doom behavior, I just checked and 
> doom-visual-bell is an optional extension.

That's true. I have misread the commit log, sorry.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 20:13:17 +0300

> Date: Sun, 18 Apr 2021 17:02:35 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
>  1305 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
>  monnier <at> iro.umontreal.ca
> 
> > I think, perhaps, introducing a new visible bell (across all significant 
> > system), that's considerably less intrusive than the ones we have today 
> > on GNU/Linux and Macos, might be an option.  And then defaulting to 
> > using that.
> >
> > Gregory suggested blinking the cursor in a different colour -- perhaps?
> >
> 
> I attach a POC of what I have in mind.

If this is being proposed as the default setting, then we should have
a different default for TTY frames, because AFAIR cursor color cannot
be changed there, right?

>   (sit-for 0.5)

I think half a second is too long, a bell should be much shorter, like
0.1 sec or something.

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

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

Gregory Heytings <gregory <at> heytings.org> writes:

>> The docstring isn't clear what "blinking" means, but they briefly set
>> the *foreground* color to red (or whatever color `error' is configured
>> to be).
>
> The foreground of the whole buffer?  IMO that's very intrusive for a
> default.  Also, this isn't the default Doom behavior, I just checked and
> doom-visual-bell is an optional extension.

No, only the foreground of the mode-line.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:02:11 +0000

[Message part 1 (text/plain, inline)]

>>> I think, perhaps, introducing a new visible bell (across all 
>>> significant system), that's considerably less intrusive than the ones 
>>> we have today on GNU/Linux and Macos, might be an option.  And then 
>>> defaulting to using that.
>>>
>>> Gregory suggested blinking the cursor in a different colour -- 
>>> perhaps?
>>
>> I attach a POC of what I have in mind.
>
> If this is being proposed as the default setting, then we should have a 
> different default for TTY frames, because AFAIR cursor color cannot be 
> changed there, right?
>

Indeed.

>>   (sit-for 0.5)
>
> I think half a second is too long, a bell should be much shorter, like 
> 0.1 sec or something.
>

Hmmm... 0.5 seconds is the duration of typical audible bells.  And with a 
sit-for, it's at most 0.5 seconds, when the user presses a key the bell 
signal disappears.  That being said, I agree with you that 0.5 seconds is 
perhaps a bit too long, so I changed it to 0.25 seconds.

I attach the updated POC, which works on non-graphical displays.

[visible-bell.el (text/plain, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 14:34:33 -0400

>> FWIW, I don't see what's "intrusive" about the "blink top and bottom lines of
>> the selected frame" which I currently see in GNU/Linux.
> In this Emacs, it blinks the two topmost lines.  Which may be a bug?

My crystal ball tells me it's a hidpi bug, indeed: it probably doubles
something where it shouldn't, so at the top, it turns into 1 line into
2 and at the bottom, the line ends up being twice too far (and probably
twice too think as well, but we don't get to see it anyway).

>> It may not be slick but it does the job and I don't find it intrusive.
>> Of course, I'm biased (I've used it for too many years), but it's
>> clearly less intrusive than the non-visual bell.
> It's more intrusive than what many people are using -- which is neither
> an audible nor a visible bell, but just the echo area saying "Quit" when
> you hit `C-g' (etc).

But those people won't be affected by a change in the default.
The only people which would see a "more intrusive" bell is those who
keep the default settings but whose environment ends up muting the
audible bell.  I don't know how common this is.


        Stefan

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: mwd <at> md5i.com, larsi <at> gnus.org, 1305 <at> debbugs.gnu.org, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 13:35:44 -0500

Gregory Heytings <gregory <at> heytings.org> writes:

>>>   (sit-for 0.5)
>>
>> I think half a second is too long, a bell should be much shorter, like
>> 0.1 sec or something.
>>
>
> Hmmm... 0.5 seconds is the duration of typical audible bells.  And with a
> sit-for, it's at most 0.5 seconds, when the user presses a key the bell
> signal disappears.  That being said, I agree with you that 0.5 seconds is
> perhaps a bit too long, so I changed it to 0.25 seconds.

Eli is correct, 0.25 is far too long.  0.1 is much better.  That is also
closer to the duration of the current behavior for `visible-bell' on
GNU/Linux (in fact, there is no reason not to use the exact same
duration as before).

In comparison with the old GNU/Linux behavior, your patch is basically
as good or better.  However, with your patch I have to wait until the
flashing is over to read the text at the bottom.  This was not the case
previously.  I think that would need to be fixed.

My guess (without looking at the code) is that we would need to make
sure that the bell function is called after the text is displayed rather
than before.  Perhaps this would require us to add a new hook or
something.

(If we do eventually decide to go this way, perhaps we could include a
few variations, for example the idea of changing the mode-line text from
Doom could be added as optional behaviour.  I don't feel very strongly
about this, but I thought it might be worth floating the idea.  It's
very easy to implement, and there is demonstrably at least some demand
for it.)

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 18:45:11 +0000

>
> Eli is correct, 0.25 is far too long.  0.1 is much better.
>

He said 0.5 is too long, I tried 0.1, and find it too short to be noticed, 
so I tried 0.25, which seems okay from my point of view.

>
> In comparison with the old GNU/Linux behavior, your patch is basically 
> as good or better.  However, with your patch I have to wait until the 
> flashing is over to read the text at the bottom.  This was not the case 
> previously.  I think that would need to be fixed.
>

It's just a quick proof of concept, perhaps it's possible to do something 
better, I'll try to do that if there's an agreement that it's a good 
starting point.  That being said, I'd be surprised if you can move your 
eye from point to the echo area in less than 0.25 seconds.  What you 
describe is annoying only if you already look at the echo area to see the 
error.

>
> If we do eventually decide to go this way, perhaps we could include a 
> few variations, for example the idea of changing the mode-line text from 
> Doom could be added as optional behaviour.
>

FWIW, I'm not sure it's right to do that, it might interfere with packages 
which use the mode-line in exotic ways.  Moreover what's the point of 
changing the color of the mode-line?  It's distracting, what the user 
should be invited to look at at that moment is the echo area, where the 
error message is (about to be) displayed.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 14:04:04 -0500

Gregory Heytings <gregory <at> heytings.org> writes:

>> Eli is correct, 0.25 is far too long.  0.1 is much better.
>>
>
> He said 0.5 is too long, I tried 0.1, and find it too short to be noticed,
> so I tried 0.25, which seems okay from my point of view.

Hmm, I find the flashing effect to be noticeable even with 0.03 or 0.05,
but I did also change the colour to red which is more visible to my
eyes.  But yes, we can't go too low.

I suggest just using the same value as with the old visible bell,
whatever that may be.

>> In comparison with the old GNU/Linux behavior, your patch is basically
>> as good or better.  However, with your patch I have to wait until the
>> flashing is over to read the text at the bottom.  This was not the case
>> previously.  I think that would need to be fixed.
>
> It's just a quick proof of concept, perhaps it's possible to do something
> better, I'll try to do that if there's an agreement that it's a good
> starting point.

Sounds good, thanks for your work here.

> That being said, I'd be surprised if you can move your
> eye from point to the echo area in less than 0.25 seconds.  What you
> describe is annoying only if you already look at the echo area to see the
> error.

I don't know which if any eye-movement was or wasn't involved as I
didn't carry out this experiment with any scientific rigor.  ;-)

So I can only tell you my experiences.  With your patch I found myself
having to wait to see the text at the bottom, which was frustrating when
I expected to see it immediately.  This was the case also with a 0.1
second delay: I saw first a block of red text before the text popped up.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, jasonspiro4 <at> gmail.com,
 monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 18 Apr 2021 19:19:06 +0000

>
> Eli is correct, 0.25 is far too long.  0.1 is much better.  That is also 
> closer to the duration of the current behavior for `visible-bell' on 
> GNU/Linux (in fact, there is no reason not to use the exact same 
> duration as before).
>

FTR, the duration of the current visible-bell on GNU/Linux is 0.2 seconds.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 jasonspiro4 <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>,
 monnier <at> iro.umontreal.ca, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 14:33:33 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> No, only the foreground of the mode-line.

I haven't seen this in action, but that sounds like a sensible variation
on visible-bell -- and should work well on most systems.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 14:37:38 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> It's more intrusive than what many people are using -- which is neither
>> an audible nor a visible bell, but just the echo area saying "Quit" when
>> you hit `C-g' (etc).
>
> But those people won't be affected by a change in the default.

Dmitry's useful overview of the various distributions (thanks) had this,
for instance:

---
Prelude and Spacemacs:

  (setq ring-bell-function 'ignore)
---

If I understand correctly, this doesn't set `visible-bell', but only
uses the default value (which is nil).  So changing the default will
indeed affect these users (until the distributions update themselves to
set visible-bell to nil).

> The only people which would see a "more intrusive" bell is those who
> keep the default settings but whose environment ends up muting the
> audible bell.  I don't know how common this is.

Me neither -- but just as a data point: In Gnome Shell the customisation
element for switching "system sounds" off is prominent, so my guess
would be that it's something people do use.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 14:38:46 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> What does tput flash do?

It flashes the terminal (both in Console and xterm).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, jasonspiro4 <at> gmail.com,
 gregory <at> heytings.org, monnier <at> iro.umontreal.ca, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 14:39:43 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> I tried in both Console and xterm on this Debian/bullseye system, and
>> `C-g' doesn't do anything visible to me with `visible-bell' switched
>> on...
>
> Did you try this in "xterm -vb"?  I get flashing here when I use that
> (my X Resources disables it so I need to use that flag).

I can't see any differences here...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 15:40:53 +0300

On 19.04.2021 15:33, Lars Ingebrigtsen wrote:
> Stefan Kangas <stefan <at> marxist.se> writes:
> 
>> No, only the foreground of the mode-line.
> 
> I haven't seen this in action, but that sounds like a sensible variation
> on visible-bell -- and should work well on most systems.

While I like to have alternatives, and the ideas are good, the color 
(non-monochrome) flashes are both more noticeable than flashing top and 
bottom lines of the frame with inverse-video, and are likely to clash 
with different color themes out there.

If it was possible to port the (intended) behavior of the GNU/Linux 
version to the other ports, that could be ideal (we don't hear many 
complaints about it).

The popular distributions out there are made by developers using macOS. 
You say the notification is different there (I haven't seen it). Perhaps 
it's indeed too much.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Mon, 19 Apr 2021 12:47:15 +0000

[Message part 1 (text/plain, inline)]

>
> While I like to have alternatives, and the ideas are good, the color 
> (non-monochrome) flashes are both more noticeable than flashing top and 
> bottom lines of the frame with inverse-video, and are likely to clash 
> with different color themes out there.
>

Not if we use the standard faces, e.g. error and match.

>
> The popular distributions out there are made by developers using macOS. 
> You say the notification is different there (I haven't seen it). Perhaps 
> it's indeed too much.
>

I posted a screenshot upthread, here it is again.

[macos.png (image/png, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com,
 Gregory Heytings <gregory <at> heytings.org>, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 14:51:45 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> If it was possible to port the (intended) behavior of the GNU/Linux
> version to the other ports, that could be ideal (we don't hear many
> complaints about it).
>
> The popular distributions out there are made by developers using
> macOS. You say the notification is different there (I haven't seen
> it). Perhaps it's indeed too much.

It's...  a lot, and we should fix it whatever else we decide to do.  I
don't remember anybody complaining about it, though -- users should
complain more.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 14:56:38 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> If you put a breakpoint inside tty_ring_bell, do you see that
> tty->TS_visible_bell is non-NULL or not?  If it's non-NULL, perhaps
> the terminal emulator has that disabled somehow?

Let's see...

gdb) print tty->TS_visible_bell 
$1 = 0x555555da95c3 "\033[?5h$<100/>\033[?5l"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Mon, 19 Apr 2021 16:01:24 +0300

On 19.04.2021 15:47, Gregory Heytings wrote:
> 
>>
>> While I like to have alternatives, and the ideas are good, the color 
>> (non-monochrome) flashes are both more noticeable than flashing top 
>> and bottom lines of the frame with inverse-video, and are likely to 
>> clash with different color themes out there.
>>
> 
> Not if we use the standard faces, e.g. error and match.

'match' for purposes other than matching?

And speaking of 'error', seeing red is most likely more obtrusive than 
the current GNU/Linux behavior.

A specific patch could convince otherwise, but the last yours I saw fell 
into that category (with the yellow flash at the bottom).

>>
>> The popular distributions out there are made by developers using 
>> macOS. You say the notification is different there (I haven't seen 
>> it). Perhaps it's indeed too much.
>>
> 
> I posted a screenshot upthread, here it is again.

The huge exclamation icon, is that the one? Looks too much indeed.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 16:04:03 +0300

On 19.04.2021 15:37, Lars Ingebrigtsen wrote:
> ---
> Prelude and Spacemacs:
> 
>    (setq ring-bell-function 'ignore)
> ---
> 
> If I understand correctly, this doesn't set `visible-bell', but only
> uses the default value (which is nil).  So changing the default will
> indeed affect these users (until the distributions update themselves to
> set visible-bell to nil).

Their uses are pretty accustomed to change, though, and to having the 
distributions maintainers resolve this kind of issues.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 16:12:16 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  mwd <at> md5i.com,  gregory <at> heytings.org,
>   1305 <at> debbugs.gnu.org,  jasonspiro4 <at> gmail.com,  monnier <at> iro.umontreal.ca
> Date: Mon, 19 Apr 2021 14:56:38 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > If you put a breakpoint inside tty_ring_bell, do you see that
> > tty->TS_visible_bell is non-NULL or not?  If it's non-NULL, perhaps
> > the terminal emulator has that disabled somehow?
> 
> Let's see...
> 
> gdb) print tty->TS_visible_bell 
> $1 = 0x555555da95c3 "\033[?5h$<100/>\033[?5l"

Then this should produce the same effect as "tput flash", I think.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Mon, 19 Apr 2021 13:16:00 +0000

>
> 'match' for purposes other than matching?
>

Why not?  That would be only a default value, to call the user's attention 
that the reason of the error is displayed there.  IMO using yellow for 
that purpose is much better than green (highlight face).

>
> And speaking of 'error', seeing red is most likely more obtrusive than 
> the current GNU/Linux behavior.
>

Do you really mean that seeing the cursor becoming red during 0.25 seconds 
is obtrusive?

The current GNU/Linux default behavior is (for those who use Gnome or KDE 
and have not disabled the system bell) to ring the system bell (typically 
during 0.5 seconds).  That's IMO far more obtrusive (in particular for 
your colleagues!) than seeing the cursor becoming red and the echo area 
flashing during a fourth of a second.

>
> The huge exclamation icon, is that the one? Looks too much indeed.
>

Yes, that's the one.  And yes, that's too much.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 08:26:53 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> It's more intrusive than what many people are using -- which is neither
>>> an audible nor a visible bell, but just the echo area saying "Quit" when
>>> you hit `C-g' (etc).
>>
>> But those people won't be affected by a change in the default.
>
> Dmitry's useful overview of the various distributions (thanks) had this,
> for instance:
>
> ---
> Prelude and Spacemacs:
>
>   (setq ring-bell-function 'ignore)
> ---
>
> If I understand correctly, this doesn't set `visible-bell', but only
> uses the default value (which is nil).  So changing the default will
> indeed affect these users (until the distributions update themselves to
> set visible-bell to nil).

Is this the scenario you have in mind?

    (setq visible-bell t)
    (setq ring-bell-function #'ignore)
    (defun foo () (interactive) (ding))

    M-x foo RET

This gives no visible bell here.

Message #625 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: Michael Welsh Duggan <mwd <at> md5i.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 1305 <at> debbugs.gnu.org, jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 08:26:59 -0500

Gregory Heytings <gregory <at> heytings.org> writes:

>> 'match' for purposes other than matching?
>
> Why not?  That would be only a default value, to call the user's attention
> that the reason of the error is displayed there.  IMO using yellow for
> that purpose is much better than green (highlight face).

I would propose using a dedicated face for this purpose.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 1305 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 13:30:49 +0000

>
> Prelude and Spacemacs:
>
> (setq ring-bell-function 'ignore)
>
> If I understand correctly, this doesn't set `visible-bell', but only 
> uses the default value (which is nil).  So changing the default will 
> indeed affect these users (until the distributions update themselves to 
> set visible-bell to nil).
>

Hmmm... No, setting ring-bell-function to ignore means that ignore is 
executed to ring the bell instead of the default behavior.  With 
ring-bell-function non-nil, visible-bell is ignored.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Mon, 19 Apr 2021 16:37:21 +0300

On 19.04.2021 16:16, Gregory Heytings wrote:
> 
>>
>> 'match' for purposes other than matching?
>>
> 
> Why not?  That would be only a default value, to call the user's 
> attention that the reason of the error is displayed there.  IMO using 
> yellow for that purpose is much better than green (highlight face).

Perhaps I'm just used to the 'inverse-video' effect on GNU/Linux, but 
that monochrome effect (having black and white switch places on two 
lines of the frame) is both noticeable but not alarming.

>> And speaking of 'error', seeing red is most likely more obtrusive than 
>> the current GNU/Linux behavior.
>>
> 
> Do you really mean that seeing the cursor becoming red during 0.25 
> seconds is obtrusive?

The cursor itself will be a mild disturbance, the colorful flash at the 
bottom should be a tad more jarring.

I'm not sure if red is a good choice, though. After all, the action we 
just performed (abort/quit) does not necessarily imply any kind of error.

> The current GNU/Linux default behavior is (for those who use Gnome or 
> KDE and have not disabled the system bell) to ring the system bell 
> (typically during 0.5 seconds).  That's IMO far more obtrusive (in 
> particular for your colleagues!) than seeing the cursor becoming red and 
> the echo area flashing during a fourth of a second.

I'm comparing to the (setq visible-bell t) behavior on GNU/Linux.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com,
 Gregory Heytings <gregory <at> heytings.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Mon, 19 Apr 2021 10:03:38 -0400

> users should complain more.  :-)

We make customization too easy.
Same with ELisp packages: it's too easy to work around a problem with
some `fboundp` or `condition-case` duct-tape, so the package authors
aren't encouraged to report problems to us (especially since even if we
fix the problem, they'll still need the duct-tape until our fix
trickles down to all their users).


        Stefan

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

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

On Mon, Apr 19, 2021 at 01:16:00PM +0000, Gregory Heytings wrote:
> 
> > 
> > The huge exclamation icon, is that the one? Looks too much indeed.
> > 
> 
> Yes, that's the one.  And yes, that's too much.

There's some discussion in bug#22746 about the macOS visual bell.
Mostly just people not being happy with it.
-- 
Alan Third

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

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

[Message part 1 (text/plain, inline)]

I attach a patch which implements a new default bell.

It can't be pushed yet (my paperwork is still not finished :(), but 
comments are welcome.

[New-default-bell.patch (text/x-diff, attachment)]

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org
Cc: Alan Third <alan <at> idiocy.org>, Michael Welsh Duggan <mwd <at> md5i.com>,
 Stefan Kangas <stefan <at> marxist.se>, 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: Tue, 20 Apr 2021 21:27:43 +0300

On 20.04.2021 17:21, Gregory Heytings wrote:
> 
> I attach a patch which implements a new default bell.
> 
> It can't be pushed yet (my paperwork is still not finished :(), but 
> comments are welcome.

In general, I like it (though the concerns about colors are still there; 
perhaps just use inverse-video in GUI as well?).

And it turns the cursor red irreversibly in my config (but not in 'emacs 
-Q').

Is nobody bothered by having this kind of visual indication while 
'visible-bell' is nil, though?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 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: Tue, 20 Apr 2021 19:19:40 +0000

>
> In general, I like it
>

Thank you :-)

>
> (though the concerns about colors are still there; perhaps just use 
> inverse-video in GUI as well?).
>

You mean, do what (setq visual-bell t) does?  There's already an option 
for that...

>
> And it turns the cursor red irreversibly in my config (but not in 'emacs 
> -Q').
>

That's rather strange, color-bell--cursor-background is saved only once, 
when visual-bell is called for the first time.  I'll try to reproduce the 
issue, but some more detailed information (e.g. with 
debug-on-variable-change) would be welcome.

>
> Is nobody bothered by having this kind of visual indication while 
> 'visible-bell' is nil, though?
>

It's easy to turn off, as indicated in NEWS: (setq ring-bell-function 
nil).  And IMO this is way better than the current situation, in which the 
default behavior depends on too many parameters that are outside the 
control of Emacs, in which the available options are different depending 
on the platform, and in which on certain platforms none of the available 
options are good.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 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 04:16:02 +0300

On 20.04.2021 22:19, Gregory Heytings wrote:
> 
>>
>> In general, I like it
>>
> 
> Thank you :-)
> 
>>
>> (though the concerns about colors are still there; perhaps just use 
>> inverse-video in GUI as well?).
>>
> 
> You mean, do what (setq visual-bell t) does?  There's already an option 
> for that...

Not on all platforms, though.

>> And it turns the cursor red irreversibly in my config (but not in 
>> 'emacs -Q').
>>
> 
> That's rather strange, color-bell--cursor-background is saved only once, 
> when visual-bell is called for the first time.  I'll try to reproduce 
> the issue, but some more detailed information (e.g. with 
> debug-on-variable-change) would be welcome.

I'll try bisecting when I have the time. In any case, it's just an 
implementation bug, not a blocker.

>> Is nobody bothered by having this kind of visual indication while 
>> 'visible-bell' is nil, though?
>>
> 
> It's easy to turn off, as indicated in NEWS: (setq ring-bell-function 
> nil).

I mean, like, semantically: this new proposal is also visual/visible.

But 'visible-bell' is nil.

> And IMO this is way better than the current situation, in which 
> the default behavior depends on too many parameters that are outside the 
> control of Emacs, in which the available options are different depending 
> on the platform, and in which on certain platforms none of the available 
> options are good.

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.

But your proposal is a close second.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 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 06:47:27 +0000

[Message part 1 (text/plain, inline)]

>>> And it turns the cursor red irreversibly in my config (but not in 
>>> 'emacs -Q').
>> 
>> That's rather strange, color-bell--cursor-background is saved only 
>> once, when visual-bell is called for the first time.  I'll try to 
>> reproduce the issue, but some more detailed information (e.g. with 
>> debug-on-variable-change) would be welcome.
>
> I'll try bisecting when I have the time. In any case, it's just an 
> implementation bug, not a blocker.
>

Does the attached patch fix the problem in your config?  It is probably 
safer to check the cursor color each time color-bell is entered.

>>> Is nobody bothered by having this kind of visual indication while 
>>> 'visible-bell' is nil, though?
>> 
>> It's easy to turn off, as indicated in NEWS: (setq ring-bell-function 
>> nil).
>
> I mean, like, semantically: this new proposal is also visual/visible.
>
> But 'visible-bell' is nil.
>

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.

>> And IMO this is way better than the current situation, in which the 
>> default behavior depends on too many parameters that are outside the 
>> control of Emacs, in which the available options are different 
>> depending on the platform, and in which on certain platforms none of 
>> the available options are good.
>
> 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.

[New-default-bell.patch (text/x-diff, attachment)]

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?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
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, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 14:05:19 +0000

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

You mean, that it's "a proven behavior with no significant complaints"? 
I'd be very surprised if many GNU/Linux users did set visible-bell to t. 
What I see is that it's not the default behavior, and that most popular 
starter kits disable the bell completely.

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

IMO having a default bell that changes the the mode-line on every error is 
a recipe for disaster.  There are too many packages that do all kinds of 
stuff with the mode-line.

>
> 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 you try the patch I sent?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>, Stefan Kangas <stefan <at> marxist.se>
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 17:12:22 +0300

On 21.04.2021 17:05, Gregory Heytings wrote:
> You mean, that it's "a proven behavior with no significant complaints"? 
> I'd be very surprised if many GNU/Linux users did set visible-bell to t. 
> What I see is that it's not the default behavior, and that most popular 
> starter kits disable the bell completely.

Most starter kit maintainers are using macOS, unfortunately.

That must affect their choice of default.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Gregory Heytings <gregory <at> heytings.org>
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, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 09:30:28 -0500

Gregory Heytings <gregory <at> heytings.org> writes:

>> 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.
>
> IMO having a default bell that changes the the mode-line on every error is
> a recipe for disaster.  There are too many packages that do all kinds of
> stuff with the mode-line.

That would just be bugs to be fixed though, right?  Most likely in those
packages themselves.

>> 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 you try the patch I sent?

Yes, of course.  I provided detailed comments in a previous post.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Gregory Heytings <gregory <at> heytings.org>,
 jasonspiro4 <at> gmail.com, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 10:33:35 -0400

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

Agreed, except I suggest to use slightly different names: `visual` becomes
`ring-bell-visual`, `t` becomes `ring-bell-beep`, `nil` becomes `ignore` and
`alarm-bell` becomes `ring-bell-function`.


        Stefan

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
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, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 14:35:51 +0000

>>> 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 you try the patch I sent?
>
> Yes, of course.  I provided detailed comments in a previous post.
>

You mean, the post to which I replied?  Okay, it wasn't clear to me that 
you were also commenting on that patch.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 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 17:45:38 +0300

On 21.04.2021 09:47, Gregory Heytings wrote:
> 
>>>> And it turns the cursor red irreversibly in my config (but not in 
>>>> 'emacs -Q').
>>>
>>> That's rather strange, color-bell--cursor-background is saved only 
>>> once, when visual-bell is called for the first time.  I'll try to 
>>> reproduce the issue, but some more detailed information (e.g. with 
>>> debug-on-variable-change) would be welcome.
>>
>> I'll try bisecting when I have the time. In any case, it's just an 
>> implementation bug, not a blocker.
>>
> 
> Does the attached patch fix the problem in your config?  It is probably 
> safer to check the cursor color each time color-bell is entered.

It does not, sorry.

Anyway, speaking about other faces you could inherit from (for the echo 
area flash), how about 'highlight' instead of 'match'?

Seems more appropriate.

>>>> Is nobody bothered by having this kind of visual indication while 
>>>> 'visible-bell' is nil, though?
>>>
>>> It's easy to turn off, as indicated in NEWS: (setq ring-bell-function 
>>> nil).
>>
>> I mean, like, semantically: this new proposal is also visual/visible.
>>
>> But 'visible-bell' is nil.
>>
> 
> 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.

Perhaps a good idea would be introduce a visible-bell-function.

But that's hard to do without overriding current customizations, as you 
described.

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

Do we have anything to compare to in other editors, BTW?

Ones that non-Emacs users employ and could consider preferable.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Gregory Heytings <gregory <at> heytings.org>
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, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 09:45:58 -0500

Gregory Heytings <gregory <at> heytings.org> writes:

>>>> 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 you try the patch I sent?
>>
>> Yes, of course.  I provided detailed comments in a previous post.
>
> You mean, the post to which I replied?  Okay, it wasn't clear to me that
> you were also commenting on that patch.

See my comments here:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=1305#574

But that was on an earlier version of your patch.  Perhaps there are any
significant differences in your most recent version?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefan <at> marxist.se>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 Gregory Heytings <gregory <at> heytings.org>, 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 17:51:55 +0300

On 21.04.2021 17:33, Stefan Monnier wrote:
>> 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
> Agreed, except I suggest to use slightly different names: `visual` becomes
> `ring-bell-visual`, `t` becomes `ring-bell-beep`, `nil` becomes `ignore` and
> `alarm-bell` becomes `ring-bell-function`.

And obsoleting the visible-bell variable?

Sounds good.

But if we're going to change the default behavior, it would (probably?) 
be weird to keep a special case in this variable for the old one.

So would 'ring-bell-visual' do what 'visible-bell' currently does, or 
will it implement one of the proposals under discussion?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Kangas <stefan <at> marxist.se>
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, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 14:53:42 +0000

[Message part 1 (text/plain, inline)]

>>>>> 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 you try the patch I sent?
>>>
>>> Yes, of course.  I provided detailed comments in a previous post.
>>
>> You mean, the post to which I replied?  Okay, it wasn't clear to me 
>> that you were also commenting on that patch.
>
> See my comments here:
>
>    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=1305#574
>
> But that was on an earlier version of your patch.  Perhaps there are any 
> significant differences in your most recent version?
>

That was not a patch, that was only a proof of concept.  I attach the 
current version of the actual proposed patch.

[New-default-bell.patch (text/x-diff, attachment)]

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Kangas <stefan <at> marxist.se>, Gregory Heytings <gregory <at> heytings.org>
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 18:08:43 +0300

On 21.04.2021 16:11, Stefan Kangas wrote:
> 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?

It's... workable.

But I do have similar reservations about flashing red so prominently 
(given that the pressing C-g does not usually indicate an error of any 
sort).

Speaking of alternative mode-line themes, though, with the one I use 
(smart-mode-line), it just makes some text on it briefly turn to bold 
(without changing its color).

That's pretty subtle, and probably better aesthetically, but it's hard 
to notice unless one is looking directly at the mode-line.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>,
 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 11:14:32 -0400

>>> 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
>> Agreed, except I suggest to use slightly different names: `visual` becomes
>> `ring-bell-visual`, `t` becomes `ring-bell-beep`, `nil` becomes `ignore` and
>> `alarm-bell` becomes `ring-bell-function`.
>
> And obsoleting the visible-bell variable?

And/or use

    (defun ring-bell-default ()
      (if visible-bell (ring-bell-visual) (ring-bell-beep)))

as the default value of `ring-bell-function`.


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>,
 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 11:18:09 -0400

> But I do have similar reservations about flashing red so prominently (given
>  that the pressing C-g does not usually indicate an error of any sort).

Why not flashing the mode line with something like:

    (let ((val (face-attribute 'mode-line :inverse-video (selected-frame) t)))
      (set-face-attribute 'mode-line (selected-frame) :inverse-video (not val))
      (sit-for 0.1)
      (set-face-attribute 'mode-line (selected-frame) :inverse-video val))


-- Stefan

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 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 16:01:23 +0000

>
> Anyway, speaking about other faces you could inherit from (for the echo 
> area flash), how about 'highlight' instead of 'match'?
>
> Seems more appropriate.
>

Yes, I noted that you'd prefer to use highlight instead of match, 
presumably for a certain logical consistency.  If highlight had been 
yellow, that's what I would have done.  For this specific case I believe 
yellow is the most appropriate color.  If inheriting from highlight is not 
okay, I'd hardcode the yellow color.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 16:14:24 +0000

>> But I do have similar reservations about flashing red so prominently 
>> (given that the pressing C-g does not usually indicate an error of any 
>> sort).
>
> Why not flashing the mode line with something like:
>

I don't understand why flashing the mode-line is among the possible 
options.  Calling the attention of the user to the mode-line is not TRT, 
it's neither where the error happened (usually at point or around point) 
nor where the error that happened is explained (in the echo area).  It's 
like flashing the fringes, there's no point in doing that when an error 
happens.

Yes, there's an option in Doom to do this.  But AFAIU Doom does that 
because it can't do better, namely, because there is no way to access the 
last error symbol in Emacs and do something with it.  This (making the 
last error symbol and data accessible from Elisp) is included in my 
proposed patch.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 13:27:25 -0400

> I don't understand why flashing the mode-line is among the possible options.

As a happy user of the current GNU/Linux `visual-bell`, I don't really
care where the flashing happens, because I don't look at it.  I just
need some flashing somewhere within my field of vision as an indicator
that "something's going on": it doesn't need to be at the place where
I need to look.

And indeed, the current GNU/Linux visual-bell works quite well for that
in my experience since it flashes both above and below, thus not
mistakenly attracting the attention to a particular spot.
In other words, for me the ideal visual bell is one that I can "feel"
more than i can "see".

I proposed the mode-line as an alternative for those who don't like the
current GNU/Linux flash, because it's one of the very few elements which
are displayed in almost 100% of the cases.  We could flash the echoarea
instead, but I think it's a bit more delicate to implement and it could
get in the way of reading the actual error message.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru,
 larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Wed, 21 Apr 2021 20:34:34 +0300

> Date: Wed, 21 Apr 2021 16:01:23 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
>  Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
>  jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca,
>  Lars Ingebrigtsen <larsi <at> gnus.org>
> 
> > Anyway, speaking about other faces you could inherit from (for the echo 
> > area flash), how about 'highlight' instead of 'match'?
> >
> > Seems more appropriate.
> 
> Yes, I noted that you'd prefer to use highlight instead of match, 
> presumably for a certain logical consistency.  If highlight had been 
> yellow, that's what I would have done.

IMO, we shouldn't use highlight for anything other than showing text
sensitive to mouse or to cursor entry.  That's what highlight was
invented for, and using the same colors for an utterly different
purpose is sub-optimal UI and UX.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 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 20:22:52 +0000

[Message part 1 (text/plain, inline)]

>> Does the attached patch fix the problem in your config?  It is probably 
>> safer to check the cursor color each time color-bell is entered.
>
> It does not, sorry.
>

I just tried to use it with Doom, Spacemacs and Prelude, and AFAICS it 
works correctly, the cursor does not become irreversibly red.  Could you 
perhaps try to create a minimal recipe with your config?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 20:26:53 +0000

>
> I proposed the mode-line as an alternative for those who don't like the 
> current GNU/Linux flash, because it's one of the very few elements which 
> are displayed in almost 100% of the cases.  We could flash the echoarea 
> instead, but I think it's a bit more delicate to implement and it could 
> get in the way of reading the actual error message.
>

The good news is that it has been implemented ;-)

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Gregory Heytings <gregory <at> heytings.org>
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, Dmitry Gutov <dgutov <at> yandex.ru>,
 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 23:27:05 +0200

Gregory Heytings <gregory <at> heytings.org> writes:

> That was not a patch, that was only a proof of concept.  I attach the
> current version of the actual proposed patch.

Thanks.  This is better than what you had before, as it does not get in
the way of reading the minibuffer.

My main objection is probably the colour, as I find the yellow to be
barely noticeable.  But this is minor, as the colours can change.
I will need to give it some further testing before I can say more.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Gregory Heytings
 <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Wed, 21 Apr 2021 22:03:43 +0000

> I proposed the mode-line as an alternative for those who don't like the
> current GNU/Linux flash, because it's one of the very few elements
> which are displayed in almost 100% of the cases.  We could flash the echoarea
> instead, but I think it's a bit more delicate to implement and it could
> get in the way of reading the actual error message.

As mentioned, I use `echo-bell.el'.  It flashes a
message at the far right of the echo area.

By default the message is " ♪♪♪♪♪♪♪♪♪", it's shown for
0.2 sec, and the echo-area background is highlighted
with "Aquamarine" for that time period.

That flash is as perceptible or imperceptible as a
user wants it to be.  Far from hiding error messages,
it makes them more visible (IMO), by briefly drawing
attention to the echo area.

This is very simple.  Just uses `ring-bell-function'.

Remove the highlighting, and that right-edge message
might not even be very noticeable.  But it's there,
and you can find it in `*Messages*', which is more than
can be said for mode-line fiddles -- IMO, presence in
`*Messages*' is a feature.  And for those modernistas
who remove the mode-line everywhere...

It sounds to me like the proposals discussed so far
complicate things for users, rather than simplifying
them.  But maybe it's just the discussion that's overly
complicated, not the actual proposals?  Is there really
something that needs "fixing" here?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 20:03:48 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> gdb) print tty->TS_visible_bell 
>> $1 = 0x555555da95c3 "\033[?5h$<100/>\033[?5l"
>
> Then this should produce the same effect as "tput flash", I think.

You'd think so.  Hm...  If I do a:

$ tput flash > /tmp/a

I get a file with:

\033[?5h\033[?5l

(Raw ESC char translated here in this email.)  Which is similar to the
string we're outputting.  cat-ing that file does not flash the terminal
here, though, so I'm wondering whether the ... shell?  is doing
something weird on this laptop.  (Doing the same with, say, "tput cup 5
20" to a file, and then cat-ing that file, works as expected.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 20:06:03 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Is this the scenario you have in mind?
>
>     (setq visible-bell t)
>     (setq ring-bell-function #'ignore)
>     (defun foo () (interactive) (ding))
>
>     M-x foo RET
>
> This gives no visible bell here.

Oh, I see -- I imagined that visible-bell had precedence over
ring-bell-function (without testing that).

But then I guess flipping the default on visible-bell won't have the
adverse effects on the popular Emacs distributions that I was worried
about?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> 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
>
> Agreed, except I suggest to use slightly different names: `visual` becomes
> `ring-bell-visual`, `t` becomes `ring-bell-beep`, `nil` becomes `ignore` and
> `alarm-bell` becomes `ring-bell-function`.

So just use function names instead of symbols?  I think, in general,
it's nice to have things like nil/t in variables like this -- it's
easier for users to deal with.

Anyway, I agree that cleaning up this area by introducing a new variable
and obsoleting the slightly confusing current state of affairs would be
nice.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 20:52:02 +0200

On Apr 25 2021, Lars Ingebrigtsen wrote:

> cat-ing that file does not flash the terminal here,

That's because the 100ms delay is missing.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 21:01:18 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>> cat-ing that file does not flash the terminal here,
>
> That's because the 100ms delay is missing.

Yeah, just cat-ing \033[?5h does inverse the console.

But what's interpreting the $<100/> bit in the string Emacs is outputting?

"\033[?5h$<100/>\033[?5l"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 21:18:04 +0200

On Apr 25 2021, Lars Ingebrigtsen wrote:

> But what's interpreting the $<100/> bit in the string Emacs is outputting?

RTFM.

       A  delay  in  milliseconds  may appear anywhere in a string capability,
       enclosed in $<..> brackets, as in el=\EK$<5>,  and  padding  characters
       are supplied by tputs(3X) to provide this delay.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 21:33:21 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>        A  delay  in  milliseconds  may appear anywhere in a string capability,
>        enclosed in $<..> brackets, as in el=\EK$<5>,  and  padding  characters
>        are supplied by tputs(3X) to provide this delay.

So tputs(3), which Emacs calls, is supposed to translate that sequence
into a number of padding characters, which should provide a delay...
and that doesn't seem to work on this Debian/bullseye laptop.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Gregory Heytings <gregory <at> heytings.org>, 1305 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, jasonspiro4 <at> gmail.com
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Sun, 25 Apr 2021 15:06:20 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Oh, I see -- I imagined that visible-bell had precedence over
> ring-bell-function (without testing that).
>
> But then I guess flipping the default on visible-bell won't have the
> adverse effects on the popular Emacs distributions that I was worried
> about?

Looks like it, yes.  I guess the main thing to be fixed before we could
change the default is to figure out what to do about the visible bell on
macOS.  The other changes discussed in this thread would be very useful
to continue working on, but they seem orthogonal to me.

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

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

>>> 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
>>
>> Agreed, except I suggest to use slightly different names: `visual` becomes
>> `ring-bell-visual`, `t` becomes `ring-bell-beep`, `nil` becomes `ignore` and
>> `alarm-bell` becomes `ring-bell-function`.
>
> So just use function names instead of symbols?  I think, in general,
> it's nice to have things like nil/t in variables like this -- it's
> easier for users to deal with.
>
> Anyway, I agree that cleaning up this area by introducing a new variable
> and obsoleting the slightly confusing current state of affairs would be
> nice.  

My point was that we can clean up without any new variable ;-)


        Stefan

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

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> My point was that we can clean up without any new variable ;-)

I'm not sure I follow you at all here.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

>> My point was that we can clean up without any new variable ;-)
>
> I'm not sure I follow you at all here.  :-/
>

Stefan M means (IIUC) that, instead of introducing a new variable to clean 
up the current situation, it is better to reuse the already existing 
ring-bell-function variable, to give it some new possible values, and at 
the same time to deprecate the visible-bell variable.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Gregory Heytings <gregory <at> heytings.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Tue, 27 Apr 2021 15:15:11 +0000

> >> My point was that we can clean up without any new variable ;-)
> > I'm not sure I follow you at all here.  :-/
> 
> Stefan M means (IIUC) that, instead of introducing a new variable to
> clean up the current situation, it is better to reuse the already existing
> ring-bell-function variable, to give it some new possible values,

+1.

> and at the same time to deprecate the visible-bell variable.

Is that needed?

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

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

Gregory Heytings <gregory <at> heytings.org> writes:

> Stefan M means (IIUC) that, instead of introducing a new variable to
> clean up the current situation, it is better to reuse the already
> existing ring-bell-function variable, to give it some new possible
> values, and at the same time to deprecate the visible-bell variable.

Sure, that makes sense, I think.  (Since `ring-bell-function' has
precedence over `visible-bell'.)

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

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

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
and reported back.

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

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

[Message part 1 (text/plain, inline)]

>> 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 (text/x-diff, attachment)]

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 Stefan Monnier <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: Thu, 29 Apr 2021 19:50:20 +0300

On 28.04.2021 16:12, Gregory Heytings wrote:
> 
> and a new prettier bell function, which would be the default

Another option would be to use your newer bell on MacOS (which has 
universally negative feedback), but keep the current one on GNU/Linux 
and Windows (maybe? very little has been said here about whether it's 
better or worse).

Which platform are you on, BTW?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Thu, 29 Apr 2021 19:48:48 +0000

>> and a new prettier bell function, which would be the default
>
> Another option would be to use your newer bell on MacOS (which has 
> universally negative feedback), but keep the current one on GNU/Linux 
> and Windows
>

IMO a default that gives the same result across platforms would be much 
better.  I'm not sure what you mean by "the current one on GNU/Linux and 
Windows": the current default is an audible bell.  If you mean "make the 
current visible-bell the default", I can only repeat that the visible bell 
on GNU/Linux is ugly.  Would you imagine such a behavior in Visual Studio, 
Sublime or Atom?

>
> Windows (maybe? very little has been said here about whether it's better 
> or worse).
>

I can't really say whether it's better or worse, with visible-bell t on 
Windows the frame briefly flashes (with the FlashWindow function), a bit 
like a flash in a terminal.  Among the three visible-bell t behaviors, 
it's the best one IMO, in the sense that it's visible and not intrusive. 
But I can't say it's nice.

>
> Which platform are you on, BTW?
>

Not sure this is relevant to the current discussion, but: 99% GNU/Linux 
(Debian), 0.95% macOS, 0.05% Windows.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Thu, 29 Apr 2021 23:17:58 +0300

On 29.04.2021 22:48, Gregory Heytings wrote:
> 
>>> and a new prettier bell function, which would be the default
>>
>> Another option would be to use your newer bell on MacOS (which has 
>> universally negative feedback), but keep the current one on GNU/Linux 
>> and Windows
>>
> 
> IMO a default that gives the same result across platforms would be much 
> better.

In theory, yes. In practice, I like the current GNU/Linux's default 
better than your proposal. We could work on converging on some version 
that satisfies all, of course.

But only replacing MacOS's bell would let us get around that.

> I'm not sure what you mean by "the current one on GNU/Linux and 
> Windows": the current default is an audible bell.  If you mean "make the 
> current visible-bell the default",

That one, yes, sorry.

> Would you imagine such a behavior in Visual 
> Studio, Sublime or Atom?

Briefly flashing some UI elements in a neutral fashion, without extra 
colors that may look out of place? Perhaps the implementation is a 
little old-fashioned, but the idea is solid, IMHO.

So from my POV, your proposal is not at that level of polish of VS 
Code/Atom either.

That's also why I asked whether somebody knows a corresponding UI 
element/animation in either of these editors we could, uh, "get inspired 
by".

>>
>> Windows (maybe? very little has been said here about whether it's 
>> better or worse).
>>
> 
> I can't really say whether it's better or worse, with visible-bell t on 
> Windows the frame briefly flashes (with the FlashWindow function), a bit 
> like a flash in a terminal.  Among the three visible-bell t behaviors, 
> it's the best one IMO, in the sense that it's visible and not intrusive.

Is it possible to replicate on other systems?

> Not sure this is relevant to the current discussion, but: 99% GNU/Linux 
> (Debian), 0.95% macOS, 0.05% Windows.

Of course it is relevant. If you were indeed a predominantly MacOS user, 
we could agree to split the difference. Apparently not, though.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Thu, 29 Apr 2021 21:46:26 +0000

[Message part 1 (text/plain, inline)]

>
> In practice, I like the current GNU/Linux's default better than your 
> proposal. We could work on converging on some version that satisfies 
> all, of course.
>

I know you like the current default on GNU/Linux, and it will remain 
available.  And what you like is not the default (you need to set 
visible-bell in your init file), so from that point of view nothing 
changes.

>> Would you imagine such a behavior in Visual Studio, Sublime or Atom?
>
> Briefly flashing some UI elements in a neutral fashion, without extra 
> colors that may look out of place?
>

Using inverse-video also creates extra colors, unless your frame happens 
to display only black on white or white on black elements on the first and 
last line.  Moreover with my patch the colors are fully configurable, so 
you can adapt them to your theme.

>
> That's also why I asked whether somebody knows a corresponding UI 
> element/animation in either of these editors we could, uh, "get inspired 
> by".
>

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.

[atom-open.png (image/png, attachment)]

[atom-save.png (image/png, attachment)]

[vscode-open.png (image/png, attachment)]

[vscode-save.png (image/png, attachment)]

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 Stefan Monnier <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: Thu, 29 Apr 2021 17:38:05 -0500

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> So from my POV, your proposal is not at that level of polish of VS
> Code/Atom either.
>
> That's also why I asked whether somebody knows a corresponding UI
> element/animation in either of these editors we could, uh, "get inspired
> by".

I installed VSCode to see what they do there.  But I failed to make it
flash or beep at me, or even present an error.  Does anyone know any way
to do that?

BTW, VSCode reasonably does not beep just because you reach the
beginning or end of the buffer, heh.

(BTW#2, I tried "searching" the Emacs sources [i.e. grepping] which made
the entire program freeze on me for half a minute.  So we are not the
only ones who sometimes fail to be asynchronous enough.)

>> I can't really say whether it's better or worse, with visible-bell t on
>> Windows the frame briefly flashes (with the FlashWindow function), a bit
>> like a flash in a terminal.  Among the three visible-bell t behaviors,
>> it's the best one IMO, in the sense that it's visible and not intrusive.
>
> Is it possible to replicate on other systems?

It would be useful if someone could post a screenshot for those of us
with no access to any Windows machines.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Kangas <stefan <at> marxist.se>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, jasonspiro4 <at> gmail.com,
 Stefan Monnier <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: Fri, 30 Apr 2021 02:11:44 +0300

On 30.04.2021 01:38, Stefan Kangas wrote:
> BTW, VSCode reasonably does not beep just because you reach the
> beginning or end of the buffer, heh.

Yep.

> (BTW#2, I tried "searching" the Emacs sources [i.e. grepping] which made
> the entire program freeze on me for half a minute.  So we are not the
> only ones who sometimes fail to be asynchronous enough.)

At least we've learned to that faster ;-)

> It would be useful if someone could post a screenshot for those of us
> with no access to any Windows machines.
+1

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Fri, 30 Apr 2021 02:23:54 +0300

On 30.04.2021 00:46, Gregory Heytings wrote:

> I know you like the current default on GNU/Linux, and it will remain 
> available.  And what you like is not the default (you need to set 
> visible-bell in your init file), so from that point of view nothing 
> changes.

Fair enough. Still, it's more "proven" that yours, so to speak.

I don't mind putting it to the vote sometime, here or some other place.

>>> Would you imagine such a behavior in Visual Studio, Sublime or Atom?
>>
>> Briefly flashing some UI elements in a neutral fashion, without extra 
>> colors that may look out of place?
>>
> 
> Using inverse-video also creates extra colors, unless your frame happens 
> to display only black on white or white on black elements on the first 
> and last line.  Moreover with my patch the colors are fully 
> configurable, so you can adapt them to your theme.

It uses only the colors that are already there, though. Just in inverse. 
Maybe it looks worse on some alternative themes, I have really only 
tried it with the default one, and themes that are similar enough to it.

>> That's also why I asked whether somebody knows a corresponding UI 
>> element/animation in either of these editors we could, uh, "get 
>> inspired by".
>>
> 
> 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.

Thanks for the screenshots.

I do not consider the 'ding' to be a warning or error notification, 
though: I far more often see it after pressing C-g myself, not when 
something unexpected happens. Otherwise a yellow notification, 
Atom-style, would be more pertinent.

But it would be interesting to try some icon-based animation in the echo 
area, like the red circle on VSCode's pic.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Thu, 29 Apr 2021 23:35:15 +0000

> But it would be interesting to try some icon-based animation 
> in the echo area

What part of the `echo-bell' "animation" in the echo
area didn't you like?

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

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

> 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

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Drew Adams <drew.adams <at> oracle.com>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Fri, 30 Apr 2021 02:52:27 +0300

On 30.04.2021 02:35, Drew Adams wrote:
> What part of the `echo-bell' "animation" in the echo
> area didn't you like?

Which animation?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 08:05:19 +0300

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 29 Apr 2021 23:17:58 +0300
> Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
>  Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
>  jasonspiro4 <at> gmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  Lars Ingebrigtsen <larsi <at> gnus.org>
> 
> > I can't really say whether it's better or worse, with visible-bell t on 
> > Windows the frame briefly flashes (with the FlashWindow function), a bit 
> > like a flash in a terminal.  Among the three visible-bell t behaviors, 
> > it's the best one IMO, in the sense that it's visible and not intrusive.
> 
> Is it possible to replicate on other systems?

Just so we are on the same page: FlashWindow on MS-Windows doesn't
necessarily flash the frame.  Or maybe I don't understand what Gregory
meant by that.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca,
 Dmitry Gutov <dgutov <at> yandex.ru>, larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 06:51:47 +0000

[Message part 1 (text/plain, inline)]

>>> I can't really say whether it's better or worse, with visible-bell t 
>>> on Windows the frame briefly flashes (with the FlashWindow function), 
>>> a bit like a flash in a terminal.  Among the three visible-bell t 
>>> behaviors, it's the best one IMO, in the sense that it's visible and 
>>> not intrusive.
>>
>> Is it possible to replicate on other systems?
>
> Just so we are on the same page: FlashWindow on MS-Windows doesn't 
> necessarily flash the frame.  Or maybe I don't understand what Gregory 
> meant by that.
>

Yes, "flash" is perhaps not the best word here, perhaps "vibrate" is 
better.

And no, I don't think it is possible to replicate that behavior on other 
systems, it's a "window manager" primitive, which AFAIU exists on Windows 
but not on macOS or GNU/Linux.

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

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

[Message part 1 (text/plain, inline)]

>>> I can't really say whether it's better or worse, with visible-bell t 
>>> on Windows the frame briefly flashes (with the FlashWindow function), 
>>> a bit like a flash in a terminal.  Among the three visible-bell t 
>>> behaviors, it's the best one IMO, in the sense that it's visible and 
>>> not intrusive.
>>
>> Is it possible to replicate on other systems?
>
> It would be useful if someone could post a screenshot for those of us 
> with no access to any Windows machines.
>

I tried to do that, but it's not possible, it's a dynamic effect.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru,
 larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 10:06:09 +0300

> Date: Fri, 30 Apr 2021 06:51:47 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Dmitry Gutov <dgutov <at> yandex.ru>, alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, 
>     mwd <at> md5i.com, stefan <at> marxist.se, jasonspiro4 <at> gmail.com, 
>     monnier <at> iro.umontreal.ca, larsi <at> gnus.org
> 
> > Just so we are on the same page: FlashWindow on MS-Windows doesn't 
> > necessarily flash the frame.  Or maybe I don't understand what Gregory 
> > meant by that.
> 
> Yes, "flash" is perhaps not the best word here, perhaps "vibrate" is 
> better.

That word still doesn't tell me what you think happens.  Can you
describe in more detail what exactly you see, and on which version of
MS-Windows?

> And no, I don't think it is possible to replicate that behavior on other 
> systems, it's a "window manager" primitive, which AFAIU exists on Windows 
> but not on macOS or GNU/Linux.

I think until now the idea was to abide by platform conventions in
this matter.  That's why we don't try to affect the audio bell,
either: we let the system sound whatever sound was configured for
that.  From that POV, using platform-specific visual cues is perfectly
fine, if such primitives exist.  Where they don't exist, we need to
emulate them, but that's another story.

So: do such WM APIs exist on X, GTK, macOS, and other platforms we
support?  (If this was already discussed, apologies.)

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Fri, 30 Apr 2021 07:09:45 +0000

[Message part 1 (text/plain, inline)]

>
> Fair enough. Still, it's more "proven" that yours, so to speak.
>

I don't know what you mean by "proven", but I never activated that visible 
bell before this discussion started, like Lars I just disabled the bell 
altogether.  And AFAICS this is also what most popular starter kits do. 
So at least to me it's not clear whether it is widely used.

>
> I don't mind putting it to the vote sometime, here or some other place.
>

I'd be very surprised if people voted for that, but indeed a vote is 
probably the best way to decide between the two.

>> Using inverse-video also creates extra colors, unless your frame 
>> happens to display only black on white or white on black elements on 
>> the first and last line.  Moreover with my patch the colors are fully 
>> configurable, so you can adapt them to your theme.
>
> It uses only the colors that are already there, though. Just in inverse.
>

Which means "new colors".  Of course from a logical viewpoint this is 
"just in inverse", but flashing a brown on white text in green on black, 
or a blue on white text in yellow on black, does create new colors that 
weren't there.  It's like photo negatives, the colors you see are not "the 
colors that were there".

>
> But it would be interesting to try some icon-based animation in the echo 
> area, like the red circle on VSCode's pic.
>

You mean, displaying such a red circle before the error message in the 
echo area?  Not sure that would be visible enough.

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

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

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru,
 larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 07:27:25 +0000

>> Yes, "flash" is perhaps not the best word here, perhaps "vibrate" is 
>> better.
>
> That word still doesn't tell me what you think happens.  Can you 
> describe in more detail what exactly you see, and on which version of 
> MS-Windows?
>

Windows 10.

I don't know how to describe this better than with the words "flash" or 
"vibrate", so I looked at the docs:

"Flashing a window means changing the appearance of its caption bar as if 
the window were changing from inactive to active status, or vice versa. 
[...] Typically, a window is flashed to inform the user that the window 
requires attention but that it does not currently have the keyboard 
focus." [1]

[1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-flashwindow

But even that doesn't describe the effect accurately, the feeling I have 
is closer to "the frame briefly vibrates".  As I said, I use Windows only 
rarely, so my feeling is perhaps not right.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru,
 larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 11:03:51 +0300

> Date: Fri, 30 Apr 2021 07:27:25 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dgutov <at> yandex.ru, alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, 
>     stefan <at> marxist.se, jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, 
>     larsi <at> gnus.org
> 
> "Flashing a window means changing the appearance of its caption bar as if 
> the window were changing from inactive to active status, or vice versa. 
> [...] Typically, a window is flashed to inform the user that the window 
> requires attention but that it does not currently have the keyboard 
> focus." [1]
> 
> [1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-flashwindow
> 
> But even that doesn't describe the effect accurately, the feeling I have 
> is closer to "the frame briefly vibrates".  As I said, I use Windows only 
> rarely, so my feeling is perhaps not right.

What I see is exactly what the MS documentation describes: the frame's
title bar blinks (a.k.a. "flickers"), which is very hard to notice;
and the corresponding tab on the task bar flashes, which is much more
prominent.  IME, this happens in all Windows versions.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, 1305 <at> debbugs.gnu.org, mwd <at> md5i.com, stefan <at> marxist.se,
 jasonspiro4 <at> gmail.com, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru,
 larsi <at> gnus.org
Subject: Re: bug#1305: All code that currently beeps should use visual bell
 instead
Date: Fri, 30 Apr 2021 08:41:33 +0000

>> "Flashing a window means changing the appearance of its caption bar as 
>> if the window were changing from inactive to active status, or vice 
>> versa. [...] Typically, a window is flashed to inform the user that the 
>> window requires attention but that it does not currently have the 
>> keyboard focus." [1]
>>
>> [1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-flashwindow
>>
>> But even that doesn't describe the effect accurately, the feeling I 
>> have is closer to "the frame briefly vibrates".  As I said, I use 
>> Windows only rarely, so my feeling is perhaps not right.
>
> What I see is exactly what the MS documentation describes: the frame's 
> title bar blinks (a.k.a. "flickers"), which is very hard to notice; and 
> the corresponding tab on the task bar flashes, which is much more 
> prominent.  IME, this happens in all Windows versions.
>

What I see on Windows 10 (without any customizations) is that the title 
bar flickers, the menu bar flickers, and the shadow effect around the 
frame flickers.  All this gives the feeling that the frame "vibrates".

And yes, the corresponding tab (on Windows 10 the default is an icon) 
flashes, its background color changes.  Indeed this is more prominent, the 
purpose of FlashWindow seems to be, as the documentation describes, "to 
inform the user that the window requires attention but that it does not 
currently have the keyboard focus", or IOW to inform the user that a 
window that it isn't the foreground window requires attention.

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

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

[Message part 1 (text/plain, inline)]

>>>> I can't really say whether it's better or worse, with visible-bell t 
>>>> on Windows the frame briefly flashes (with the FlashWindow function), 
>>>> a bit like a flash in a terminal.  Among the three visible-bell t 
>>>> behaviors, it's the best one IMO, in the sense that it's visible and 
>>>> not intrusive.
>>> 
>>> Is it possible to replicate on other systems?
>> 
>> It would be useful if someone could post a screenshot for those of us 
>> with no access to any Windows machines.
>
> I tried to do that, but it's not possible, it's a dynamic effect.
>

I tried again; see the attached screencast.

[windows.mp4 (video/mp4, attachment)]

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Sat, 1 May 2021 01:22:24 +0300

On 30.04.2021 10:09, Gregory Heytings wrote:
> And AFAICS this is also what most popular starter kits do. So at least 
> to me it's not clear whether it is widely used.

better-defaults is an old project which has been there for at least a 
decade in some form (and has a fair amount of stars on its archived 
repository on github: https://github.com/technomancy/better-defaults). 
It's the original "emacs starter kit".

So yes, it must be widely used.

>> But it would be interesting to try some icon-based animation in the 
>> echo area, like the red circle on VSCode's pic.
>>
> 
> You mean, displaying such a red circle before the error message in the 
> echo area?  Not sure that would be visible enough.

Something like that, with a blinking or some brief "busy" animation.

A moving reddish shape should bring enough attention, but of course 
different users have different levels of sensitivity (as the discussion 
in bug#47574 has shown). Only a practical experiment can tell.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Fri, 30 Apr 2021 23:19:20 +0000

>> And AFAICS this is also what most popular starter kits do. So at least 
>> to me it's not clear whether it is widely used.
>
> better-defaults is an old project which has been there for at least a 
> decade in some form (and has a fair amount of stars on its archived 
> repository on github: https://github.com/technomancy/better-defaults). 
> It's the original "emacs starter kit".
>

Amusingly, it's the only "better default" that isn't described in the 
README, and against which there's a open issue: 
https://github.com/technomancy/better-defaults/issues/27 .

>
> A moving reddish shape should bring enough attention, but of course 
> different users have different levels of sensitivity (as the discussion 
> in bug#47574 has shown). Only a practical experiment can tell.
>

Moving???  Why do you think this would be better than simply blinking the 
echo area?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Sat, 1 May 2021 02:28:49 +0300

On 01.05.2021 02:19, Gregory Heytings wrote:
> Amusingly, it's the only "better default" that isn't described in the 
> README, and against which there's a open issue: 
> https://github.com/technomancy/better-defaults/issues/27 .

Have you read the comments? People complain about macOS behavior, and 
the first proposed "fix" was to make it work close to how it works on 
GNU/Linux (except flashing the mode-line, probably because that is 
easier to implement).

Hence the reply: "that's strange; the behavior you describe is how it 
already works for me".

>> A moving reddish shape should bring enough attention, but of course 
>> different users have different levels of sensitivity (as the 
>> discussion in bug#47574 has shown). Only a practical experiment can tell.
>>
> 
> Moving???  Why do you think this would be better than simply blinking 
> the echo area?

"Blinking" is also movement. I don't have a specific animation in mind.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Sat, 01 May 2021 00:00:44 +0000

>
> Have you read the comments?
>

Of course I did.

>
> People complain about macOS behavior, and the first proposed "fix" was 
> to make it work close to how it works on GNU/Linux (except flashing the 
> mode-line, probably because that is easier to implement).
>

And the fix used by the author of the issue, and agreed with by the one 
who suggested that "first proposed fix", is to turn visible-bell off.

Anyway, I fear this discussion will never end.  I proposed a patch, I'd 
suggest you propose another one that does what you think would be TRT.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: [External] : bug#1305: All code that currently beeps should use
 visual bell instead
Date: Sat, 1 May 2021 00:05:19 +0000

> > Moving???  Why do you think this would be better
> > than simply blinking the echo area?
> 
> "Blinking" is also movement. I don't have a specific
> animation in mind.

"Blinking" is the "animation" provided by
`echo-bell-mode' (you asked for that): the echo
area is briefly highlighted with a different
background.

Users can easily control the duration of this
"flash", as well as its color.  And they can
control what text, if any, is shown at the right
edge of the area.  The default text is musical
note chars.

Different behavior & appearance are appreciated
differently by different users.  One user's
valued indication is another's annoyance.  This
simple mode lets you easily have no indication
(mode off) or any degree of interruption you
might want.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Sat, 1 May 2021 03:57:38 +0300

On 01.05.2021 03:00, Gregory Heytings wrote:

> And the fix used by the author of the issue, and agreed with by the one 
> who suggested that "first proposed fix", is to turn visible-bell off.

You said there's no evidence of this behavior having been used widely.

I presented such evidence. The rest is minor details (one report with 2 
participants, compared to 800 stars, or 3K stars for the previous 
version of that starter kit).

> Anyway, I fear this discussion will never end.  I proposed a patch, I'd 
> suggest you propose another one that does what you think would be TRT.

At this point I'm starting to wonder whether

  (setq ring-bell-function #'ignore)

would not be a good compromise, after all.

A poll could provide some better data, though.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Drew Adams <drew.adams <at> oracle.com>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 1 May 2021 04:08:33 +0300

On 01.05.2021 03:05, Drew Adams wrote:
> Users can easily control the duration of this
> "flash", as well as its color.  And they can
> control what text, if any, is shown at the right
> edge of the area.  The default text is musical
> note chars.

BTW, this aquamarine looks a bit nicer than the yellow flash in 
Gregory's version, and I like that it's implemented solely in Elisp.

(https://www.emacswiki.org/emacs/echo-bell.el)

Still not sure if that is the behavior we want to provide OOTB (no Atom 
or VSCode-level of "slickness" in there), but why not ask people.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 1 May 2021 02:05:19 +0000

> > Users can easily control the duration of this
> > "flash", as well as its color.  And they can
> > control what text, if any, is shown at the right
> > edge of the area.  The default text is musical
> > note chars.
> 
> BTW, this aquamarine looks a bit nicer than the yellow flash in
> Gregory's version, and I like that it's implemented solely in Elisp.
> 
> (https://urldefense.com/v3/__https://www.emacswiki.org/emacs/echo-
> bell.el__;!!GqivPVa7Brio!NXvNy4ePYJu7-yFxNANdGuqcHj0K8fXxFMLl-
> Y720teI23EXPdOS6nALvnt_cBpq$ )
> 
> Still not sure if that is the behavior we want to provide OOTB (no Atom
> or VSCode-level of "slickness" in there), but why not ask people.

For whatever you guys decide to do:

. There's the question of the default behavior.

. And there's the question of how easy it is for
  users to modify the behavior in different ways.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: 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>, Stefan Kangas <stefan <at> marxist.se>,
 jasonspiro4 <at> gmail.com, Stefan Monnier <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: Sat, 01 May 2021 07:50:07 +0000

>> And the fix used by the author of the issue, and agreed with by the one 
>> who suggested that "first proposed fix", is to turn visible-bell off.
>
> You said there's no evidence of this behavior having been used widely.
>

No.  I said it is ugly.  You said it isn't, and it is in your opinion 
"proven" enough to become the default on three platforms.  I said I 
disagree with this, it is not used enough to be "proven" enough.  The 
"evidence" you now presented show that a few hundred people are using it, 
which doesn't prove anything.  Of course, it's there, so some use it.

What I see is instead that there are various solutions available that 
implement a "better" visual bell, which shows that the default one isn't 
satisfactory.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 01 May 2021 07:50:13 +0000

>
> What part of the `echo-bell' "animation" in the echo area didn't you 
> like?
>

You may have seen earlier in this thread that having to wait for the end 
of the animation to see the error message is not considered optimal.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 1 May 2021 14:13:13 +0000

> > What part of the `echo-bell' "animation" in the echo area didn't you
> > like?
> 
> You may have seen earlier in this thread that having to wait for the
> end of the animation to see the error message is not considered optimal.

"is not considered": passive voice.  Who doesn't
consider it, and why?  Have the passive voicers
actually tried it?

The default period to "wait" is 0.2 sec.  Having to
wait 0.2 sec is "not considered optimal" by default?
Really?  In that case, change the default to 0.02
sec or whatever the passive voices consider optimal.

Seriously, this thread seems way overblown to me.
All the talk of different platforms, animations...

What's needed - regardless of what default behavior
is chosen, is a simple way for users to customize
things.  I mentioned the kinds of things.  And I
mentioned that it's an additional advantage to have
the indication be recorded in *Messages*.

Provide that additional advantage and some ways for
users to customize the behavior in various ways, and
be sure to do it with Lisp, and you should get a
usable, cross-platform feature.  Then you can argue
about the default behavior...

It should be clear, I hope, that I don't really care
what Emacs does in this regard, beyond thinking that
things should be kept simple and flexible.  I didn't
write the initial code behind echo-bell (Miles Bader
did), and I don't even use it!  I just turn off sound,
for the most part, and I don't need an alarm of any kind.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 01 May 2021 10:28:11 -0400

> You may have seen earlier in this thread that having to wait for the end of
> the animation to see the error message is not considered optimal.

That's the current behavior of `visual-bell` and I can't remember anyone
complaining about it.  So maybe the complaint you refer to was due to
a slightly longer duration of the animation?

[ When I saw that complaint, it rang quite right to me; I thought "yeah,
  of course the error message should be visible during the flash, just
  as is the case with the GNU/Linux visual-bell I use and love", and
  then I hit `C-g` and saw that the message only appears after the
  flashing ;-)  ]


        Stefan

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 01 May 2021 16:48:51 +0000

>> You may have seen earlier in this thread that having to wait for the 
>> end of the animation to see the error message is not considered 
>> optimal.
>
> That's the current behavior of `visual-bell` and I can't remember anyone 
> complaining about it.  So maybe the complaint you refer to was due to a 
> slightly longer duration of the animation?
>

Ah yes, indeed!  I don't know why I didn't see this when Stefan K made 
that objection.  OTOH, now that I'm using the patch in which there is no 
such delay (except when 'ding' is used), I agree with him that it's better 
to see the error message immediately.  Perhaps this delay is less visible, 
from a psychological viewpoint, with an inverse video flash?

>
> [ When I saw that complaint, it rang quite right to me; I thought "yeah, 
> of course the error message should be visible during the flash, just as 
> is the case with the GNU/Linux visual-bell I use and love", and then I 
> hit `C-g` and saw that the message only appears after the flashing ;-) ]
>

I'm reassured to see that I wasn't alone to err in the darkness of 
ignorance ;-)

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Dmitry Gutov <dgutov <at> yandex.ru>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: RE: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sat, 01 May 2021 16:55:55 +0000

>
> Have the passive voicers actually tried it?
>

Yes, and I tried it, too, and after trying a solution where you have to 
wait and another where you don't have to wait I agree that this slight 
delay is a bit annoying.  As I just said to Stefan M, my feeling is that 
this delay is more annoying when flashing with a background color instead 
of flashing with an inverse video effect.

>
> In that case, change the default to 0.02 sec or whatever the passive 
> voices consider optimal.
>

The flash can't be too short, otherwise it isn't visible anymore...

>
> What's needed - regardless of what default behavior is chosen, is a 
> simple way for users to customize things.
>

It's already there, and it's already used: ring-bell-function.  What is 
(if I'm not mistaken) discussed in this thread is what a better default 
would be / whether another default behavior would be better.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, "1305 <at> debbugs.gnu.org" <1305 <at> debbugs.gnu.org>,
 Michael Welsh Duggan <mwd <at> md5i.com>,
 "jasonspiro4 <at> gmail.com" <jasonspiro4 <at> gmail.com>,
 Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#1305: [External] : bug#1305: All code that currently beeps
 should use visual bell instead
Date: Sun, 2 May 2021 05:44:32 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> [ When I saw that complaint, it rang quite right to me; I thought "yeah,
>   of course the error message should be visible during the flash, just
>   as is the case with the GNU/Linux visual-bell I use and love", and
>   then I hit `C-g` and saw that the message only appears after the
>   flashing ;-)  ]

Good catch!  Sorry for introducing the confusion.  But at least we
identified something we could improve, I guess...

(FWIW, I think I pressed `C-g C-g', in which case you can actually read
"Quit" while it is flashing.  ;-))

Previous Next

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