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

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