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

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]

> 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

[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

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

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

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

[Drew Adams]

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

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

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