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

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

[Jason Spiro]

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

2008/11/7 Stefan Monnier <monnier@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.

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

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> retitle 1305 All code that currently beeps should use visual bell instead
bug#1305: Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere
Changed bug title to `All code that currently beeps should use visual bell instead' from `Please disable the audible bell by default, to avoid discouraging newbies in crowded offices and elsewhere'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

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

[Drew Adams]

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

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

[Jason Spiro]

2008/11/8 Drew Adams <drew.adams@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).

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

[Eli Zaretskii]

> Date: Sat, 8 Nov 2008 23:08:48 -0500
> From: "Jason Spiro" <jasonspiro4@gmail.com>
> Cc: bug-gnu-emacs@gnu.org, 1305@emacsbugs.donarmstrong.com,
> 	control@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'.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 8 Nov 2008 19:57:59 -0800
> Cc: bug-gnu-emacs@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.

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

[Drew Adams]

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

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <jasonspiro4@gmail.com>, <bug-gnu-emacs@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.

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

[Stefan Monnier]

> 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

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

[Drew Adams]

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

bug#1305: All code that currently beeps should usevisual bellinstead

[Drew Adams]

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

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

[Lennart Borgman]

On Mon, Nov 10, 2008 at 3:07 AM, Stefan Monnier
<monnier@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.

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

[Stefan Monnier]

> 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

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

[Lennart Borgman]

On Mon, Nov 10, 2008 at 4:22 PM, Stefan Monnier
<monnier@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.

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

[Jason A. Spiro]

2008/11/10 Lennart Borgman <lennart.borgman@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 .

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

[Richard M. Stallman]

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

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

[Jason Spiro]

2008/11/10 Richard M. Stallman <rms@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.

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

[Richard M. Stallman]

    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.

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

[Jason Spiro]

2008/11/11 Richard M. Stallman <rms@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?

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

[Stefan Kangas]

Stefan Monnier <monnier@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.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 17 Apr 2021 01:06:54 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, 1305@debbugs.gnu.org, Drew Adams <drew.adams@oracle.com>, 
> 	jasonspiro4@gmail.com
> 
> Stefan Monnier <monnier@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?

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]


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

[-- Attachment #2: Type: image/png, Size: 51893 bytes --]

[-- Attachment #3: Type: image/png, Size: 120764 bytes --]

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

[Eli Zaretskii]

> Date: Sat, 17 Apr 2021 12:31:27 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: jasonspiro4@gmail.com, 1305@debbugs.gnu.org,
>  Stefan Kangas <stefan@marxist.se>, Stefan Monnier <monnier@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.)

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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?

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Gregory Heytings <gregory@heytings.org>,
>   jasonspiro4@gmail.com,  1305@debbugs.gnu.org,  monnier@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.

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.  :-)

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.)

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

[Gregory Heytings]

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

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Gregory Heytings]

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

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

[Basil L. Contovounesios]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@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

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

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

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

[Michael Welsh Duggan]

Gregory Heytings <gregory@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@md5i.com)

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

[Gregory Heytings]

>> 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?

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

[Michael Welsh Duggan]

Gregory Heytings <gregory@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@md5i.com)

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

[Gregory Heytings]

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

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

[Drew Adams]

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

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

[Lars Ingebrigtsen]

Gregory Heytings <gregory@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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).

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@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.

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

[Stefan Kangas]

Stefan Kangas <stefan@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.

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Stefan Monnier]

> 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

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

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

[Stefan Monnier]

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

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

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

[Dmitry Gutov]

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.

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@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.

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.

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

[Gregory Heytings]

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

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]


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

[-- Attachment #2: Type: text/plain, Size: 950 bytes --]

(defface visible-bell-face `((t (:background "yellow"))) "")
(defface visible-bell-cursor-face `((t (:background "red"))) "")
(defvar visible-bell--cursor-background nil)
(defvar visible-bell--face-remapping nil)
(defun visible-bell ()
  (unless visible-bell--cursor-background
    (setq visible-bell--cursor-background
          (face-attribute 'cursor :background)))
  (set-face-attribute 'cursor nil :background
                      (face-attribute 'visible-bell-cursor-face :background))
  (with-current-buffer " *Echo Area 0*"
    (setq-local visible-bell--face-remapping
                (face-remap-add-relative 'default 'visible-bell-face)))
  (sit-for 0.5)
  (set-face-attribute 'cursor nil :background visible-bell--cursor-background)
   (with-current-buffer " *Echo Area 0*"
    (face-remap-remove-relative visible-bell--face-remapping)))
(setq ring-bell-function #'visible-bell)
(setq visible-bell nil) ;; just in case

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

[Eli Zaretskii]

> Date: Sun, 18 Apr 2021 17:02:35 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: Michael Welsh Duggan <mwd@md5i.com>, jasonspiro4@gmail.com,
>  1305@debbugs.gnu.org, Stefan Kangas <stefan@marxist.se>,
>  monnier@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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]


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

[-- Attachment #2: Type: text/plain, Size: 971 bytes --]

(defface visible-bell-face
  '((((type tty)) :background "red")(t (:background "yellow"))) "")
(defface visible-bell-cursor-face `((t (:background "red"))) "")
(defvar visible-bell--cursor-background nil)
(defvar visible-bell--face-remapping nil)
(defun visible-bell ()
  (unless visible-bell--cursor-background
    (setq visible-bell--cursor-background
          (face-attribute 'cursor :background)))
  (set-face-attribute 'cursor nil :background
		      (face-attribute 'visible-bell-cursor-face :background))
  (with-current-buffer " *Echo Area 0*"
    (setq-local visible-bell--face-remapping
                (face-remap-add-relative 'default 'visible-bell-face)))
  (sit-for 0.25)
  (set-face-attribute 'cursor nil :background visible-bell--cursor-background)
  (with-current-buffer " *Echo Area 0*"
    (face-remap-remove-relative visible-bell--face-remapping)))
(setq ring-bell-function #'visible-bell)
(setq visible-bell nil) ;; just in case

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

[Stefan Kangas]

Gregory Heytings <gregory@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.)

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

[Gregory Heytings]

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

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

[Stefan Kangas]

Gregory Heytings <gregory@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.

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

[Gregory Heytings]

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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 18 Apr 2021 14:36:55 +0200
> Cc: Michael Welsh Duggan <mwd@md5i.com>,
>  Gregory Heytings <gregory@heytings.org>, 1305@debbugs.gnu.org,
>  jasonspiro4@gmail.com, monnier@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  mwd@md5i.com,  gregory@heytings.org,
>   1305@debbugs.gnu.org,  jasonspiro4@gmail.com,  monnier@iro.umontreal.ca
> Date: Sun, 18 Apr 2021 17:11:21 +0200
> 
> Eli Zaretskii <eliz@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?

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

[Eli Zaretskii]

> Date: Sun, 18 Apr 2021 18:23:57 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 1305@debbugs.gnu.org, mwd@md5i.com, stefan@marxist.se, gregory@heytings.org,
>  jasonspiro4@gmail.com, monnier@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?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  mwd@md5i.com,  gregory@heytings.org,
>   1305@debbugs.gnu.org,  jasonspiro4@gmail.com,  monnier@iro.umontreal.ca
> Date: Mon, 19 Apr 2021 14:56:38 +0200
> 
> Eli Zaretskii <eliz@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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).

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@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

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

[Dmitry Gutov]

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.

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

[Dmitry Gutov]

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

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

[Gregory Heytings]

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

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

[Stefan Kangas]

Dmitry Gutov <dgutov@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.

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

[Gregory Heytings]

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

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

[Dmitry Gutov]

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.

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

[Stefan Kangas]

Gregory Heytings <gregory@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.

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

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

[Dmitry Gutov]

On 19.04.2021 15:33, Lars Ingebrigtsen wrote:
> Stefan Kangas <stefan@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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]


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

[-- Attachment #2: Type: image/png, Size: 120764 bytes --]

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

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

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

[Stefan Kangas]

Gregory Heytings <gregory@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.

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

[Dmitry Gutov]

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.

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

[Alan Third]

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

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]


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.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=New-default-bell.patch, Size: 6711 bytes --]

From 3d0ca9bbd35ef3ddc41a68fed1ec7acdde14a268 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Tue, 20 Apr 2021 14:11:24 +0000
Subject: [PATCH] New default bell.

* lisp/simple.el (color-bell): New default bell, which briefly flashes
the cursor and the echo area when an error occurs.
(color-bell-echo-area-face, color-bell-cursor-face): New faces.
(color-bell-ignored-errors, color-bell-duration): New user options.

* src/eval.c (last-error-symbol, last-error-data): New variables.
(signal_or_quit): Set the new variables.

* lisp/face-remap.el (face-remap-remove-relative, buffer-face-mode-face,
text-scale-mode-step): Autoload them.

* etc/NEWS: Document the change.
---
 etc/NEWS           | 10 ++++++++
 lisp/face-remap.el |  3 +++
 lisp/simple.el     | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 src/eval.c         | 11 +++++++++
 4 files changed, 81 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index e39aa7b437..4203e0b40d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -272,6 +272,16 @@ commands.  The new keystrokes are 'C-x x g' ('revert-buffer'),
 ** Commands 'set-frame-width' and 'set-frame-height' can now get their
 input using the minibuffer.
 
++++
+** The default value of 'ring-bell-function' is now non-nil.
+When an error occurs, Emacs will by default briefly flash the cursor
+and the echo area.  This effect can be customized with the user options
+color-bell-duration, color-bell-cursor-face, color-bell-echo-area-face
+and color-bell-ignored-errors.  To restore the previous behavior,
+add the following to your init file:
+
+(setq ring-bell-function nil)
+
 \f
 * Editing Changes in Emacs 28.1
 
diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index 5914ee4a20..df4c59913c 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -142,6 +142,7 @@ face-remap-add-relative
       (force-mode-line-update))
     (cons face specs)))
 
+;;;###autoload
 (defun face-remap-remove-relative (cookie)
   "Remove a face remapping previously added by `face-remap-add-relative'.
 COOKIE should be the return value from that function."
@@ -210,6 +211,7 @@ face-remap-set-base
 ;; ----------------------------------------------------------------
 ;; text-scale-mode
 
+;;;###autoload
 (defcustom text-scale-mode-step 1.2
   "Scale factor used by `text-scale-mode'.
 Each positive or negative step scales the default face height by this amount."
@@ -397,6 +399,7 @@ text-scale-adjust
 ;; ----------------------------------------------------------------
 ;; buffer-face-mode
 
+;;;###autoload
 (defcustom buffer-face-mode-face 'variable-pitch
   "The face specification used by `buffer-face-mode'.
 It may contain any value suitable for a `face' text property,
diff --git a/lisp/simple.el b/lisp/simple.el
index 999755a642..00c37b4d40 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8511,7 +8511,64 @@ play-sound-file
 	(plist-put sound :device device))
     (push 'sound sound)
     (play-sound sound)))
+\f
+(defface color-bell-echo-area-face
+  `((((type tty)) (:inherit error :inverse-video t))
+    (t (:inherit match)))
+  "Face used by `color-bell' to flash the echo area when an error happened."
+  :version "28.1")
+
+(defface color-bell-cursor-face
+  `((t (:inherit error)))
+  "Face used by `color-bell' to flash the cursor when an error happened.
+The cursor is flashed with the foreground color of that face; it is not
+flashed in terminals."
+  :version "28.1")
+
+(defcustom color-bell-ignored-errors nil
+  "List of errors symbols ignored by `color-bell'.
+Error symbols that are present in this list are ignored by `color-bell', and
+are displayed without flashing the cursor and echo area.
+For example, the value '(quit beginning-of-buffer end-of-buffer) disables
+`color-bell' on \\[keyboard-quit], and for beginning and end of buffer errors.
+To find the symbol of an error, type \\[eval-expression] last-error-symbol \
+\\[newline] immediately
+after the error happened, without using \\[indent-for-tab-command] for \
+completion."
+  :type 'list
+  :version "28.1")
+
+(defcustom color-bell-duration 0.25
+  "Maximum duration of the `color-bell' flash.
+The flash stops when input is available."
+  :type 'float
+  :version "28.1")
 
+(defvar color-bell--cursor-background nil)
+(defvar color-bell--face-remapping nil)
+
+(defun color-bell ()
+  (unless (memq last-error-symbol color-bell-ignored-errors)
+    (unless color-bell--cursor-background
+      (setq color-bell--cursor-background
+            (face-attribute 'cursor :background)))
+    (set-face-attribute 'cursor nil :background
+                        (face-attribute 'color-bell-cursor-face :foreground
+                                        nil t))
+    (with-current-buffer " *Echo Area 0*"
+      (when color-bell--face-remapping
+        (face-remap-remove-relative color-bell--face-remapping))
+      (setq-local color-bell--face-remapping
+                  (face-remap-add-relative 'default
+                                           'color-bell-echo-area-face)))
+    (message (error-message-string (cons last-error-symbol nil)))
+    (sit-for color-bell-duration)
+    (set-face-attribute 'cursor nil :background color-bell--cursor-background)
+    (with-current-buffer " *Echo Area 0*"
+      (face-remap-remove-relative color-bell--face-remapping)
+      (setq color-bell--face-remapping nil))))
+
+(setq ring-bell-function #'color-bell)
 \f
 (defcustom read-mail-command 'rmail
   "Your preference for a mail reading package.
diff --git a/src/eval.c b/src/eval.c
index fd93f5b9e1..ea012eef77 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1716,6 +1716,9 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit)
 #endif
 #endif
 
+  Vlast_error_symbol = real_error_symbol;
+  Vlast_error_data = (NILP (error_symbol) ? Fcdr (data) : data);
+
   /* This hook is used by edebug.  */
   if (! NILP (Vsignal_hook_function)
       && ! NILP (error_symbol)
@@ -4321,6 +4324,14 @@ syms_of_eval (void)
 The Edebug package uses this to regain control.  */);
   Vsignal_hook_function = Qnil;
 
+  DEFVAR_LISP ("last-error-symbol", Vlast_error_symbol,
+	       doc: /* Symbol of the last error.  */);
+  Vlast_error_symbol = Qnil;
+
+  DEFVAR_LISP ("last-error-data", Vlast_error_data,
+	       doc: /* Data of the last error.  */);
+  Vlast_error_data = Qnil;
+
   DEFVAR_LISP ("debug-on-signal", Vdebug_on_signal,
 	       doc: /* Non-nil means call the debugger regardless of condition handlers.
 Note that `debug-on-error', `debug-on-quit' and friends
-- 
2.30.2

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

[Dmitry Gutov]

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?

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

[Gregory Heytings]

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

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]


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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=New-default-bell.patch, Size: 6776 bytes --]

From 21f2a9946c70d8973648fa3dfb30c82732ea682e Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Wed, 21 Apr 2021 06:36:06 +0000
Subject: [PATCH] New default bell.

* lisp/simple.el (color-bell): New default bell, which briefly flashes
the cursor and the echo area when an error occurs.
(color-bell-echo-area-face, color-bell-cursor-face): New faces.
(color-bell-ignored-errors, color-bell-duration): New user options.

* src/eval.c (last-error-symbol, last-error-data): New variables.
(signal_or_quit): Set the new variables.

* lisp/face-remap.el (face-remap-remove-relative, buffer-face-mode-face,
text-scale-mode-step): Autoload them.

* etc/NEWS: Document the change.
---
 etc/NEWS           | 10 ++++++++
 lisp/face-remap.el |  3 +++
 lisp/simple.el     | 58 ++++++++++++++++++++++++++++++++++++++++++++++
 src/eval.c         | 11 +++++++++
 4 files changed, 82 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index e39aa7b437..4203e0b40d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -272,6 +272,16 @@ commands.  The new keystrokes are 'C-x x g' ('revert-buffer'),
 ** Commands 'set-frame-width' and 'set-frame-height' can now get their
 input using the minibuffer.
 
++++
+** The default value of 'ring-bell-function' is now non-nil.
+When an error occurs, Emacs will by default briefly flash the cursor
+and the echo area.  This effect can be customized with the user options
+color-bell-duration, color-bell-cursor-face, color-bell-echo-area-face
+and color-bell-ignored-errors.  To restore the previous behavior,
+add the following to your init file:
+
+(setq ring-bell-function nil)
+
 \f
 * Editing Changes in Emacs 28.1
 
diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index 5914ee4a20..df4c59913c 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -142,6 +142,7 @@ face-remap-add-relative
       (force-mode-line-update))
     (cons face specs)))
 
+;;;###autoload
 (defun face-remap-remove-relative (cookie)
   "Remove a face remapping previously added by `face-remap-add-relative'.
 COOKIE should be the return value from that function."
@@ -210,6 +211,7 @@ face-remap-set-base
 ;; ----------------------------------------------------------------
 ;; text-scale-mode
 
+;;;###autoload
 (defcustom text-scale-mode-step 1.2
   "Scale factor used by `text-scale-mode'.
 Each positive or negative step scales the default face height by this amount."
@@ -397,6 +399,7 @@ text-scale-adjust
 ;; ----------------------------------------------------------------
 ;; buffer-face-mode
 
+;;;###autoload
 (defcustom buffer-face-mode-face 'variable-pitch
   "The face specification used by `buffer-face-mode'.
 It may contain any value suitable for a `face' text property,
diff --git a/lisp/simple.el b/lisp/simple.el
index 999755a642..c07296fef4 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8511,7 +8511,65 @@ play-sound-file
 	(plist-put sound :device device))
     (push 'sound sound)
     (play-sound sound)))
+\f
+(defface color-bell-echo-area-face
+  `((((type tty)) (:inherit error :inverse-video t))
+    (t (:inherit match)))
+  "Face used by `color-bell' to flash the echo area when an error happened."
+  :version "28.1")
+
+(defface color-bell-cursor-face
+  `((t (:inherit error)))
+  "Face used by `color-bell' to flash the cursor when an error happened.
+The cursor is flashed with the foreground color of that face; it is not
+flashed in terminals."
+  :version "28.1")
+
+(defcustom color-bell-ignored-errors nil
+  "List of errors symbols ignored by `color-bell'.
+Error symbols that are present in this list are ignored by `color-bell', and
+are displayed without flashing the cursor and echo area.
+For example, the value '(quit beginning-of-buffer end-of-buffer) disables
+`color-bell' on \\[keyboard-quit], and for beginning and end of buffer errors.
+To find the symbol of an error, type \\[eval-expression] last-error-symbol \
+\\[newline] immediately
+after the error happened, without using \\[indent-for-tab-command] for \
+completion."
+  :type 'list
+  :version "28.1")
+
+(defcustom color-bell-duration 0.25
+  "Maximum duration of the `color-bell' flash.
+The flash stops when input is available."
+  :type 'float
+  :version "28.1")
 
+(defvar color-bell--cursor-background nil)
+(defvar color-bell--face-remapping nil)
+
+(defun color-bell ()
+  (unless (memq last-error-symbol color-bell-ignored-errors)
+    (if (not (eq (face-attribute 'cursor :background)
+                 color-bell--cursor-background))
+        (setq color-bell--cursor-background
+            (face-attribute 'cursor :background)))
+    (set-face-attribute 'cursor nil :background
+                        (face-attribute 'color-bell-cursor-face :foreground
+                                        nil t))
+    (with-current-buffer " *Echo Area 0*"
+      (when color-bell--face-remapping
+        (face-remap-remove-relative color-bell--face-remapping))
+      (setq-local color-bell--face-remapping
+                  (face-remap-add-relative 'default
+                                           'color-bell-echo-area-face)))
+    (message (error-message-string (cons last-error-symbol nil)))
+    (sit-for color-bell-duration)
+    (set-face-attribute 'cursor nil :background color-bell--cursor-background)
+    (with-current-buffer " *Echo Area 0*"
+      (face-remap-remove-relative color-bell--face-remapping)
+      (setq color-bell--face-remapping nil))))
+
+(setq ring-bell-function #'color-bell)
 \f
 (defcustom read-mail-command 'rmail
   "Your preference for a mail reading package.
diff --git a/src/eval.c b/src/eval.c
index fd93f5b9e1..ea012eef77 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1716,6 +1716,9 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit)
 #endif
 #endif
 
+  Vlast_error_symbol = real_error_symbol;
+  Vlast_error_data = (NILP (error_symbol) ? Fcdr (data) : data);
+
   /* This hook is used by edebug.  */
   if (! NILP (Vsignal_hook_function)
       && ! NILP (error_symbol)
@@ -4321,6 +4324,14 @@ syms_of_eval (void)
 The Edebug package uses this to regain control.  */);
   Vsignal_hook_function = Qnil;
 
+  DEFVAR_LISP ("last-error-symbol", Vlast_error_symbol,
+	       doc: /* Symbol of the last error.  */);
+  Vlast_error_symbol = Qnil;
+
+  DEFVAR_LISP ("last-error-data", Vlast_error_data,
+	       doc: /* Data of the last error.  */);
+  Vlast_error_data = Qnil;
+
   DEFVAR_LISP ("debug-on-signal", Vdebug_on_signal,
 	       doc: /* Non-nil means call the debugger regardless of condition handlers.
 Note that `debug-on-error', `debug-on-quit' and friends
-- 
2.30.2

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

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

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

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

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

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

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

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

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

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

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

Did anyone have any objections to doing it that way?

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

[Gregory Heytings]

>>> 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?

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

[Dmitry Gutov]

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.

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

[Stefan Kangas]

Gregory Heytings <gregory@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.

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

[Gregory Heytings]

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

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

[Stefan Kangas]

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

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]


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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=New-default-bell.patch, Size: 7306 bytes --]

From 1327c4e13d3c0f3ba0cf93c43ad82645365123df Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Wed, 21 Apr 2021 14:52:01 +0000
Subject: [PATCH] New default bell.

* lisp/simple.el (color-bell): New default bell, which briefly flashes
the cursor and the echo area when an error occurs.
(color-bell-echo-area-face, color-bell-cursor-face): New faces.
(color-bell-ignored-errors, color-bell-duration): New user options.

* src/eval.c (last-error-symbol, last-error-data): New variables.
(signal_or_quit): Set the new variables.

* lisp/face-remap.el (face-remap-remove-relative, buffer-face-mode-face,
text-scale-mode-step): Autoload them.

* etc/NEWS: Document the change.
---
 etc/NEWS           | 10 +++++++
 lisp/face-remap.el |  3 ++
 lisp/simple.el     | 69 ++++++++++++++++++++++++++++++++++++++++++++++
 src/eval.c         | 11 ++++++++
 4 files changed, 93 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index e39aa7b437..4203e0b40d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -272,6 +272,16 @@ commands.  The new keystrokes are 'C-x x g' ('revert-buffer'),
 ** Commands 'set-frame-width' and 'set-frame-height' can now get their
 input using the minibuffer.
 
++++
+** The default value of 'ring-bell-function' is now non-nil.
+When an error occurs, Emacs will by default briefly flash the cursor
+and the echo area.  This effect can be customized with the user options
+color-bell-duration, color-bell-cursor-face, color-bell-echo-area-face
+and color-bell-ignored-errors.  To restore the previous behavior,
+add the following to your init file:
+
+(setq ring-bell-function nil)
+
 \f
 * Editing Changes in Emacs 28.1
 
diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index 5914ee4a20..df4c59913c 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -142,6 +142,7 @@ face-remap-add-relative
       (force-mode-line-update))
     (cons face specs)))
 
+;;;###autoload
 (defun face-remap-remove-relative (cookie)
   "Remove a face remapping previously added by `face-remap-add-relative'.
 COOKIE should be the return value from that function."
@@ -210,6 +211,7 @@ face-remap-set-base
 ;; ----------------------------------------------------------------
 ;; text-scale-mode
 
+;;;###autoload
 (defcustom text-scale-mode-step 1.2
   "Scale factor used by `text-scale-mode'.
 Each positive or negative step scales the default face height by this amount."
@@ -397,6 +399,7 @@ text-scale-adjust
 ;; ----------------------------------------------------------------
 ;; buffer-face-mode
 
+;;;###autoload
 (defcustom buffer-face-mode-face 'variable-pitch
   "The face specification used by `buffer-face-mode'.
 It may contain any value suitable for a `face' text property,
diff --git a/lisp/simple.el b/lisp/simple.el
index 999755a642..94984ba6d9 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8511,7 +8511,76 @@ play-sound-file
 	(plist-put sound :device device))
     (push 'sound sound)
     (play-sound sound)))
+\f
+(defface color-bell-echo-area-face
+  `((((type tty)) (:inherit error :inverse-video t))
+    (t (:inherit match)))
+  "Face used by `color-bell' to flash the echo area when an error happened."
+  :version "28.1")
+
+(defface color-bell-cursor-face
+  `((t (:inherit error)))
+  "Face used by `color-bell' to flash the cursor when an error happened.
+The cursor is flashed with the foreground color of that face; it is not
+flashed in terminals."
+  :version "28.1")
+
+(defcustom color-bell-ignored-errors nil
+  "List of errors symbols ignored by `color-bell'.
+Error symbols that are present in this list are ignored by `color-bell', and
+are displayed without flashing the cursor and echo area.
+For example, the value '(quit beginning-of-buffer end-of-buffer) disables
+`color-bell' on \\[keyboard-quit], and for beginning and end of buffer errors.
+To find the symbol of an error, type \\[eval-expression] last-error-symbol \
+\\[newline] immediately
+after the error happened, without using \\[indent-for-tab-command] for \
+completion."
+  :type 'list
+  :version "28.1")
+
+(defcustom color-bell-duration 0.25
+  "Maximum duration of the `color-bell' flash.
+The flash stops when input is available."
+  :type 'float
+  :version "28.1")
+
+(defvar color-bell--cursor-background nil)
+(defvar color-bell--face-remapping nil)
+
+(defun color-bell ()
+  (unless (memq last-error-symbol color-bell-ignored-errors)
+    (if (not (eq (face-attribute 'cursor :background)
+                 color-bell--cursor-background))
+        (setq color-bell--cursor-background
+            (face-attribute 'cursor :background)))
+    (set-face-attribute 'cursor nil :background
+                        (face-attribute 'color-bell-cursor-face
+                                        :foreground nil t))
+    (let* ((no-minibuffer (= (minibuffer-depth) 0))
+           (inside-minibuffer (minibufferp (current-buffer)))
+           (buffer-name (if no-minibuffer
+                            " *Echo Area 0*"
+                          (format " *Minibuf-%d*" (minibuffer-depth))))
+           (buffer (get-buffer buffer-name)))
+      (unless inside-minibuffer
+        (with-current-buffer buffer
+          (when color-bell--face-remapping
+            (face-remap-remove-relative color-bell--face-remapping))
+          (setq-local color-bell--face-remapping
+                      (face-remap-add-relative 'default
+                                               'color-bell-echo-area-face))))
+      (if no-minibuffer
+          (message (error-message-string (cons last-error-symbol nil))))
+      (sit-for color-bell-duration)
+      (set-face-attribute 'cursor nil
+                          :background color-bell--cursor-background)
+      (unless inside-minibuffer
+        (if (buffer-live-p buffer)
+            (with-current-buffer buffer
+              (face-remap-remove-relative color-bell--face-remapping)
+              (setq color-bell--face-remapping nil)))))))
 
+(setq ring-bell-function #'color-bell)
 \f
 (defcustom read-mail-command 'rmail
   "Your preference for a mail reading package.
diff --git a/src/eval.c b/src/eval.c
index fd93f5b9e1..ea012eef77 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1716,6 +1716,9 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit)
 #endif
 #endif
 
+  Vlast_error_symbol = real_error_symbol;
+  Vlast_error_data = (NILP (error_symbol) ? Fcdr (data) : data);
+
   /* This hook is used by edebug.  */
   if (! NILP (Vsignal_hook_function)
       && ! NILP (error_symbol)
@@ -4321,6 +4324,14 @@ syms_of_eval (void)
 The Edebug package uses this to regain control.  */);
   Vsignal_hook_function = Qnil;
 
+  DEFVAR_LISP ("last-error-symbol", Vlast_error_symbol,
+	       doc: /* Symbol of the last error.  */);
+  Vlast_error_symbol = Qnil;
+
+  DEFVAR_LISP ("last-error-data", Vlast_error_data,
+	       doc: /* Data of the last error.  */);
+  Vlast_error_data = Qnil;
+
   DEFVAR_LISP ("debug-on-signal", Vdebug_on_signal,
 	       doc: /* Non-nil means call the debugger regardless of condition handlers.
 Note that `debug-on-error', `debug-on-quit' and friends
-- 
2.30.2

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

[Stefan Kangas]

Gregory Heytings <gregory@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.

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

[Stefan Monnier]

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

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

[Dmitry Gutov]

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?

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

[Stefan Monnier]

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

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

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

[Stefan Monnier]

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

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

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

[Gregory Heytings]

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

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

[Drew Adams]

> >> 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?

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

[Lars Ingebrigtsen]

Gregory Heytings <gregory@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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]


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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=New-default-bell.patch, Size: 9180 bytes --]

From d3b6bd69cd5e9283fa0a4189ce7d01bcb76e6654 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Wed, 28 Apr 2021 12:55:07 +0000
Subject: [PATCH] New default bell.

* lisp/simple.el (ring-bell-color): New default bell, which briefly flashes
the cursor and the echo area when an error occurs.
(ring-bell-color-echo-area-face, ring-bell-color-cursor-face): New faces.
(ring-bell-color-ignored-errors, ring-bell-color-duration): New user options.

* src/eval.c (last-error-symbol, last-error-data): New variables.
(signal_or_quit): Set the new variables.

* src/dispnew.c (ding): New variable.
(ding): Set the new variable.

* lisp/face-remap.el (face-remap-remove-relative, buffer-face-mode-face,
text-scale-mode-step): Autoload them.

* etc/NEWS: Document the change.
---
 etc/NEWS           | 10 ++++++
 lisp/face-remap.el |  3 ++
 lisp/simple.el     | 84 ++++++++++++++++++++++++++++++++++++++++++++++
 src/dispnew.c      |  8 +++++
 src/eval.c         | 11 ++++++
 5 files changed, 116 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index 9bf232ac02..4f2a0fedb3 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -276,6 +276,16 @@ commands.  The new keystrokes are 'C-x x g' ('revert-buffer'),
 ** Commands 'set-frame-width' and 'set-frame-height' can now get their
 input using the minibuffer.
 
++++
+** The default value of 'ring-bell-function' is now non-nil.
+When an error occurs, Emacs will by default briefly flash the cursor
+and the echo area.  This effect can be customized with the user options
+ring-bell-color-duration, ring-bell-color-cursor-face,
+ring-bell-color-echo-area-face and ring-bell-color-ignored-errors.
+To restore the previous behavior, add the following to your init file:
+
+(setq ring-bell-function nil)
+
 \f
 * Editing Changes in Emacs 28.1
 
diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index 5914ee4a20..df4c59913c 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -142,6 +142,7 @@ face-remap-add-relative
       (force-mode-line-update))
     (cons face specs)))
 
+;;;###autoload
 (defun face-remap-remove-relative (cookie)
   "Remove a face remapping previously added by `face-remap-add-relative'.
 COOKIE should be the return value from that function."
@@ -210,6 +211,7 @@ face-remap-set-base
 ;; ----------------------------------------------------------------
 ;; text-scale-mode
 
+;;;###autoload
 (defcustom text-scale-mode-step 1.2
   "Scale factor used by `text-scale-mode'.
 Each positive or negative step scales the default face height by this amount."
@@ -397,6 +399,7 @@ text-scale-adjust
 ;; ----------------------------------------------------------------
 ;; buffer-face-mode
 
+;;;###autoload
 (defcustom buffer-face-mode-face 'variable-pitch
   "The face specification used by `buffer-face-mode'.
 It may contain any value suitable for a `face' text property,
diff --git a/lisp/simple.el b/lisp/simple.el
index 26eb8cad7f..874593d957 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -8514,7 +8514,91 @@ play-sound-file
 	(plist-put sound :device device))
     (push 'sound sound)
     (play-sound sound)))
+\f
+(defface ring-bell-color-echo-area-face
+  `((((type tty)) (:inherit error :inverse-video t))
+    (t (:background "yellow1")))
+  "Face used by `ring-bell-color' to flash the echo area when an error happened."
+  :version "28.1")
+
+(defface ring-bell-color-cursor-face
+  `((t (:inherit error)))
+  "Face used by `ring-bell-color' to flash the cursor when an error happened.
+The cursor flashes with the foreground color of that face; it does not
+flash in terminals."
+  :version "28.1")
+
+(defcustom ring-bell-color-ignored-errors nil
+  "List of errors symbols ignored by `ring-bell-color'.
+Error symbols that are present in this list are ignored by `ring-bell-color',
+and their error messages are displayed without flashing the cursor and echo
+area.
+For example, the value '(quit beginning-of-buffer end-of-buffer) disables
+`ring-bell-color' on \\[keyboard-quit], and for beginning and end of buffer errors.
+To find the symbol of an error, type \\[eval-expression] last-error-symbol \
+\\[newline] immediately
+after the error happened, without using \\[indent-for-tab-command] for \
+completion."
+  :type 'list
+  :version "28.1")
+
+(defcustom ring-bell-color-duration 0.2
+  "Maximum duration of the `ring-bell-color' flash, in seconds.
+The flash stops after that duration, or when input is available, whichever
+comes first."
+  :type 'float
+  :version "28.1")
+
+(defvar ring-bell-color--cursor-background nil)
+(defvar ring-bell-color--face-remapping nil)
+
+(defun ring-bell-color ()
+  "Flash the cursor and echo area with colors when an error occurs.
+The flash is controlled by the variables `ring-bell-color-duration' and
+`ring-bell-color-ignored-errors', and by the faces
+`ring-bell-color-cursor-face' and `ring-bell-color-echo-area-face'.
+Inside the minibuffer, only the cursor flashes, during half the duration
+of `ring-bell-color-duration'."
+  (unless (memq last-error-symbol ring-bell-color-ignored-errors)
+    (if (not (eq (face-attribute 'cursor :background)
+                 ring-bell-color--cursor-background))
+        (setq ring-bell-color--cursor-background
+              (face-attribute 'cursor :background)))
+    (set-face-attribute 'cursor nil :background
+                        (face-attribute 'ring-bell-color-cursor-face
+                                        :foreground nil t))
+    (let* ((minibuffer (window-buffer (minibuffer-window)))
+           (inside-minibuffer (minibufferp (current-buffer)))
+           (active-minibuffer (> (minibuffer-depth) 0))
+           (buffer (if (and ding active-minibuffer)
+                       minibuffer
+                     (get-buffer " *Echo Area 0*"))))
+      (unless inside-minibuffer
+        (with-current-buffer buffer
+          (when ring-bell-color--face-remapping
+            (face-remap-remove-relative ring-bell-color--face-remapping))
+          (setq-local ring-bell-color--face-remapping
+                      (face-remap-add-relative
+                       'default
+                       'ring-bell-color-echo-area-face)))
+        (let ((set-message-function nil))
+          (message
+           (if ding ""
+             (error-message-string
+              (cons last-error-symbol last-error-data))))))
+      (sit-for (if inside-minibuffer
+                   (/ ring-bell-color-duration 2)
+                 ring-bell-color-duration))
+      (if ring-bell-color--cursor-background
+          (set-face-attribute 'cursor nil
+                              :background ring-bell-color--cursor-background))
+      (unless inside-minibuffer
+        (if (buffer-live-p buffer)
+            (with-current-buffer buffer
+              (face-remap-remove-relative ring-bell-color--face-remapping)
+              (setq ring-bell-color--face-remapping nil)))))))
 
+(setq ring-bell-function #'ring-bell-color)
 \f
 (defcustom read-mail-command 'rmail
   "Your preference for a mail reading package.
diff --git a/src/dispnew.c b/src/dispnew.c
index b3f7be67e0..38d82328b0 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -5995,6 +5995,8 @@ DEFUN ("ding", Fding, Sding, 0, 1, 0,
 terminate any keyboard macro currently executing.  */)
   (Lisp_Object arg)
 {
+  Vding = 1;
+
   if (!NILP (arg))
     {
       if (noninteractive)
@@ -6005,6 +6007,8 @@ DEFUN ("ding", Fding, Sding, 0, 1, 0,
   else
     bitch_at_user ();
 
+  Vding = 0;
+
   return Qnil;
 }
 
@@ -6620,6 +6624,10 @@ syms_of_display (void)
 
 See also `ring-bell-function'.  */);
 
+  DEFVAR_BOOL ("ding", Vding,
+	       doc: /* Whether `ding' is being executed.  */);
+  Vding = 0;
+
   DEFVAR_BOOL ("no-redraw-on-reenter", no_redraw_on_reenter,
 	       doc: /* Non-nil means no need to redraw entire frame after suspending.
 A non-nil value is useful if the terminal can automatically preserve
diff --git a/src/eval.c b/src/eval.c
index aeedcc50cc..12d4d4f9ad 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1809,6 +1809,9 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit)
 #endif
 #endif
 
+  Vlast_error_symbol = real_error_symbol;
+  Vlast_error_data = (NILP (error_symbol) ? Fcdr (data) : data);
+
   /* This hook is used by edebug.  */
   if (! NILP (Vsignal_hook_function)
       && ! NILP (error_symbol)
@@ -4430,6 +4433,14 @@ syms_of_eval (void)
 The Edebug package uses this to regain control.  */);
   Vsignal_hook_function = Qnil;
 
+  DEFVAR_LISP ("last-error-symbol", Vlast_error_symbol,
+	       doc: /* Symbol of the last error.  */);
+  Vlast_error_symbol = Qnil;
+
+  DEFVAR_LISP ("last-error-data", Vlast_error_data,
+	       doc: /* Data of the last error.  */);
+  Vlast_error_data = Qnil;
+
   DEFVAR_LISP ("debug-on-signal", Vdebug_on_signal,
 	       doc: /* Non-nil means call the debugger regardless of condition handlers.
 Note that `debug-on-error', `debug-on-quit' and friends
-- 
2.30.2

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

[Dmitry Gutov]

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?

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

[Gregory Heytings]

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

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]


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

[-- Attachment #2: Type: image/png, Size: 10745 bytes --]

[-- Attachment #3: Type: image/png, Size: 15700 bytes --]

[-- Attachment #4: Type: image/png, Size: 15139 bytes --]

[-- Attachment #5: Type: image/png, Size: 28078 bytes --]

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

[Dmitry Gutov]

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.

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

[Drew Adams]

> 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?

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

[Dmitry Gutov]

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?

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

[Gregory Heytings]

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

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

[Drew Adams]

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

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

[Gregory Heytings]

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

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

[Stefan Monnier]

> 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

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

[Gregory Heytings]

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

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

[Stefan Kangas]

Stefan Monnier <monnier@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.  ;-))

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]


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

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

>> 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?

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

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

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

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

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

[Drew Adams]

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

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

[Dmitry Gutov]

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.

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

[Drew Adams]

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

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

[Stefan Monnier]

> 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

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

[Gregory Heytings]

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

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

[Stefan Kangas]

Dmitry Gutov <dgutov@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.

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

[Dmitry Gutov]

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

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]


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

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]


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

[-- Attachment #2: Type: video/mp4, Size: 60382 bytes --]

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 29 Apr 2021 23:17:58 +0300
> Cc: Alan Third <alan@idiocy.org>, 1305@debbugs.gnu.org,
>  Michael Welsh Duggan <mwd@md5i.com>, Stefan Kangas <stefan@marxist.se>,
>  jasonspiro4@gmail.com, Stefan Monnier <monnier@iro.umontreal.ca>,
>  Lars Ingebrigtsen <larsi@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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]


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

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

[Eli Zaretskii]

> Date: Fri, 30 Apr 2021 06:51:47 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Dmitry Gutov <dgutov@yandex.ru>, alan@idiocy.org, 1305@debbugs.gnu.org, 
>     mwd@md5i.com, stefan@marxist.se, jasonspiro4@gmail.com, 
>     monnier@iro.umontreal.ca, larsi@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.)

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

[Gregory Heytings]

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

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

[Eli Zaretskii]

> Date: Fri, 30 Apr 2021 07:27:25 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: dgutov@yandex.ru, alan@idiocy.org, 1305@debbugs.gnu.org, mwd@md5i.com, 
>     stefan@marxist.se, jasonspiro4@gmail.com, monnier@iro.umontreal.ca, 
>     larsi@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.

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

[Gregory Heytings]

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

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

[Dmitry Gutov]

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.

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

[Stefan Monnier]

> 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

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

[Gregory Heytings]

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

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

[Stefan Monnier]

> 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

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

[Gregory Heytings]

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

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

[Drew Adams]

> 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?

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

[Dmitry Gutov]

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.

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

[Gregory Heytings]

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

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

[Eli Zaretskii]

> Date: Wed, 21 Apr 2021 16:01:23 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: Alan Third <alan@idiocy.org>, 1305@debbugs.gnu.org,
>  Michael Welsh Duggan <mwd@md5i.com>, Stefan Kangas <stefan@marxist.se>,
>  jasonspiro4@gmail.com, monnier@iro.umontreal.ca,
>  Lars Ingebrigtsen <larsi@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.

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

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]


>> 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?

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

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

[Stefan Monnier]

> 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

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

[Drew Adams]

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

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

[Eli Zaretskii]

> Date: Sat, 17 Apr 2021 20:59:52 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: jasonspiro4@gmail.com, 1305@debbugs.gnu.org,
>  Stefan Kangas <stefan@marxist.se>, monnier@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.

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

[Gregory Heytings]

>
> 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?

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

[Eli Zaretskii]

> Date: Sun, 18 Apr 2021 11:10:45 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, jasonspiro4@gmail.com, 1305@debbugs.gnu.org, 
>     stefan@marxist.se, monnier@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.

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

[Drew Adams]

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

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

[Drew Adams]

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

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

[Dmitry Gutov]

On 17.04.2021 15:55, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@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.

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

[Xavier Maillard]

   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

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

[Tim Connors]

"Jason Spiro" <jasonspiro4@gmail.com> wrote:
> 2008/11/10 Richard M. Stallman <rms@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

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

[Jason Spiro]

2008/11/17 Tim Connors <tim.w.connors@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?

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

[Sven Joachim]

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

> 2008/11/17 Tim Connors <tim.w.connors@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

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

[Stefan Monnier]

> 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