* bug#1305: All code that currently beeps should use visual bell instead
@ 2008-11-09 1:50 Jason Spiro
2008-11-09 2:00 ` Processed: " Emacs bug Tracking System
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Jason Spiro @ 2008-11-09 1:50 UTC (permalink / raw
To: control; +Cc: bug-gnu-emacs, 1305
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Processed: Re: bug#1305: All code that currently beeps should use visual bell instead
2008-11-09 1:50 bug#1305: All code that currently beeps should use visual bell instead Jason Spiro
@ 2008-11-09 2:00 ` Emacs bug Tracking System
2008-11-09 3:57 ` bug#1305: All code that currently beeps should use visual bellinstead Drew Adams
2008-11-10 21:25 ` Xavier Maillard
2 siblings, 0 replies; 180+ messages in thread
From: Emacs bug Tracking System @ 2008-11-09 2:00 UTC (permalink / raw
To: Jason Spiro; +Cc: Emacs Bugs
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)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 1:50 bug#1305: All code that currently beeps should use visual bell instead Jason Spiro
2008-11-09 2:00 ` Processed: " Emacs bug Tracking System
@ 2008-11-09 3:57 ` Drew Adams
2008-11-09 4:08 ` Jason Spiro
2008-11-09 19:04 ` Eli Zaretskii
2008-11-10 21:25 ` Xavier Maillard
2 siblings, 2 replies; 180+ messages in thread
From: Drew Adams @ 2008-11-09 3:57 UTC (permalink / raw
To: 'Jason Spiro', 1305, control; +Cc: bug-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 3:57 ` bug#1305: All code that currently beeps should use visual bellinstead Drew Adams
@ 2008-11-09 4:08 ` Jason Spiro
2008-11-09 19:17 ` Eli Zaretskii
2008-11-09 19:04 ` Eli Zaretskii
1 sibling, 1 reply; 180+ messages in thread
From: Jason Spiro @ 2008-11-09 4:08 UTC (permalink / raw
To: Drew Adams; +Cc: bug-gnu-emacs, 1305, control
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).
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 3:57 ` bug#1305: All code that currently beeps should use visual bellinstead Drew Adams
2008-11-09 4:08 ` Jason Spiro
@ 2008-11-09 19:04 ` Eli Zaretskii
2008-11-09 19:19 ` Drew Adams
1 sibling, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2008-11-09 19:04 UTC (permalink / raw
To: Drew Adams, 1305; +Cc: jasonspiro4, bug-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 4:08 ` Jason Spiro
@ 2008-11-09 19:17 ` Eli Zaretskii
0 siblings, 0 replies; 180+ messages in thread
From: Eli Zaretskii @ 2008-11-09 19:17 UTC (permalink / raw
To: Jason Spiro, 1305; +Cc: bug-gnu-emacs
> 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'.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 19:04 ` Eli Zaretskii
@ 2008-11-09 19:19 ` Drew Adams
2008-11-09 20:00 ` Eli Zaretskii
0 siblings, 1 reply; 180+ messages in thread
From: Drew Adams @ 2008-11-09 19:19 UTC (permalink / raw
To: 'Eli Zaretskii', 1305; +Cc: jasonspiro4, bug-gnu-emacs
> > 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 19:19 ` Drew Adams
@ 2008-11-09 20:00 ` Eli Zaretskii
2008-11-10 2:07 ` Stefan Monnier
0 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2008-11-09 20:00 UTC (permalink / raw
To: Drew Adams; +Cc: jasonspiro4, bug-gnu-emacs, 1305
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-09 20:00 ` Eli Zaretskii
@ 2008-11-10 2:07 ` Stefan Monnier
2008-11-10 6:28 ` Drew Adams
` (3 more replies)
0 siblings, 4 replies; 180+ messages in thread
From: Stefan Monnier @ 2008-11-10 2:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: jasonspiro4, bug-gnu-emacs, 1305
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 2:07 ` Stefan Monnier
@ 2008-11-10 6:28 ` Drew Adams
2008-11-11 21:20 ` bug#1305: All code that currently beeps should usevisual bellinstead Drew Adams
2008-11-10 8:34 ` bug#1305: All code that currently beeps should use visual bellinstead Lennart Borgman
` (2 subsequent siblings)
3 siblings, 1 reply; 180+ messages in thread
From: Drew Adams @ 2008-11-10 6:28 UTC (permalink / raw
To: 'Stefan Monnier', 'Eli Zaretskii'
Cc: jasonspiro4, bug-gnu-emacs, 1305
> > 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 2:07 ` Stefan Monnier
2008-11-10 6:28 ` Drew Adams
@ 2008-11-10 8:34 ` Lennart Borgman
2008-11-10 15:22 ` Stefan Monnier
2008-11-10 22:17 ` Richard M. Stallman
2021-04-17 6:06 ` bug#1305: All code that currently beeps should use visual bell instead Stefan Kangas
3 siblings, 1 reply; 180+ messages in thread
From: Lennart Borgman @ 2008-11-10 8:34 UTC (permalink / raw
To: Stefan Monnier, 1305; +Cc: bug-gnu-emacs, jasonspiro4
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 8:34 ` bug#1305: All code that currently beeps should use visual bellinstead Lennart Borgman
@ 2008-11-10 15:22 ` Stefan Monnier
2008-11-10 16:58 ` Lennart Borgman
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Monnier @ 2008-11-10 15:22 UTC (permalink / raw
To: Lennart Borgman; +Cc: bug-gnu-emacs, 1305, jasonspiro4
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 15:22 ` Stefan Monnier
@ 2008-11-10 16:58 ` Lennart Borgman
2008-11-11 18:38 ` Jason A. Spiro
0 siblings, 1 reply; 180+ messages in thread
From: Lennart Borgman @ 2008-11-10 16:58 UTC (permalink / raw
To: Stefan Monnier; +Cc: 1305, Jason Spiro
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2008-11-09 1:50 bug#1305: All code that currently beeps should use visual bell instead Jason Spiro
2008-11-09 2:00 ` Processed: " Emacs bug Tracking System
2008-11-09 3:57 ` bug#1305: All code that currently beeps should use visual bellinstead Drew Adams
@ 2008-11-10 21:25 ` Xavier Maillard
2 siblings, 0 replies; 180+ messages in thread
From: Xavier Maillard @ 2008-11-10 21:25 UTC (permalink / raw
To: Jason Spiro, 1305; +Cc: bug-gnu-emacs, bug-submit-list, 1305, control
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 2:07 ` Stefan Monnier
2008-11-10 6:28 ` Drew Adams
2008-11-10 8:34 ` bug#1305: All code that currently beeps should use visual bellinstead Lennart Borgman
@ 2008-11-10 22:17 ` Richard M. Stallman
2008-11-11 18:50 ` Jason Spiro
2021-04-17 6:06 ` bug#1305: All code that currently beeps should use visual bell instead Stefan Kangas
3 siblings, 1 reply; 180+ messages in thread
From: Richard M. Stallman @ 2008-11-10 22:17 UTC (permalink / raw
To: Stefan Monnier, 1305; +Cc: bug-submit-list, bug-gnu-emacs, jasonspiro4, 1305
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".
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 16:58 ` Lennart Borgman
@ 2008-11-11 18:38 ` Jason A. Spiro
0 siblings, 0 replies; 180+ messages in thread
From: Jason A. Spiro @ 2008-11-11 18:38 UTC (permalink / raw
To: Lennart Borgman; +Cc: 1305
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 .
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-10 22:17 ` Richard M. Stallman
@ 2008-11-11 18:50 ` Jason Spiro
2008-11-12 3:33 ` Richard M. Stallman
0 siblings, 1 reply; 180+ messages in thread
From: Jason Spiro @ 2008-11-11 18:50 UTC (permalink / raw
To: rms; +Cc: bug-submit-list, bug-gnu-emacs, 1305
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should usevisual bellinstead
2008-11-10 6:28 ` Drew Adams
@ 2008-11-11 21:20 ` Drew Adams
0 siblings, 0 replies; 180+ messages in thread
From: Drew Adams @ 2008-11-11 21:20 UTC (permalink / raw
To: 1305, 'Stefan Monnier', 'Eli Zaretskii'
Cc: jasonspiro4, bug-gnu-emacs
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-11 18:50 ` Jason Spiro
@ 2008-11-12 3:33 ` Richard M. Stallman
2008-11-13 7:41 ` Jason Spiro
0 siblings, 1 reply; 180+ messages in thread
From: Richard M. Stallman @ 2008-11-12 3:33 UTC (permalink / raw
To: Jason Spiro; +Cc: bug-submit-list, bug-gnu-emacs, 1305
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-12 3:33 ` Richard M. Stallman
@ 2008-11-13 7:41 ` Jason Spiro
0 siblings, 0 replies; 180+ messages in thread
From: Jason Spiro @ 2008-11-13 7:41 UTC (permalink / raw
To: rms; +Cc: bug-submit-list, bug-gnu-emacs, 1305
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
@ 2008-11-17 7:32 Tim Connors
2008-11-17 7:37 ` Jason Spiro
0 siblings, 1 reply; 180+ messages in thread
From: Tim Connors @ 2008-11-17 7:32 UTC (permalink / raw
To: Jason Spiro; +Cc: rms, bug-gnu-emacs, bug-submit-list, 1305
"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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-17 7:32 bug#1305: All code that currently beeps should use visual bellinstead Tim Connors
@ 2008-11-17 7:37 ` Jason Spiro
2008-11-17 8:01 ` Sven Joachim
2008-11-17 14:52 ` Stefan Monnier
0 siblings, 2 replies; 180+ messages in thread
From: Jason Spiro @ 2008-11-17 7:37 UTC (permalink / raw
To: Tim Connors; +Cc: rms, bug-gnu-emacs, bug-submit-list, 1305
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-17 7:37 ` Jason Spiro
@ 2008-11-17 8:01 ` Sven Joachim
2008-11-17 14:52 ` Stefan Monnier
1 sibling, 0 replies; 180+ messages in thread
From: Sven Joachim @ 2008-11-17 8:01 UTC (permalink / raw
To: Jason Spiro; +Cc: 1305, rms, Tim Connors
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bellinstead
2008-11-17 7:37 ` Jason Spiro
2008-11-17 8:01 ` Sven Joachim
@ 2008-11-17 14:52 ` Stefan Monnier
1 sibling, 0 replies; 180+ messages in thread
From: Stefan Monnier @ 2008-11-17 14:52 UTC (permalink / raw
To: Jason Spiro; +Cc: Tim Connors, bug-gnu-emacs, bug-submit-list, 1305, rms
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2008-11-10 2:07 ` Stefan Monnier
` (2 preceding siblings ...)
2008-11-10 22:17 ` Richard M. Stallman
@ 2021-04-17 6:06 ` Stefan Kangas
2021-04-17 7:03 ` Eli Zaretskii
2021-04-17 11:54 ` Lars Ingebrigtsen
3 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-17 6:06 UTC (permalink / raw
To: Stefan Monnier; +Cc: 1305, jasonspiro4
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 6:06 ` bug#1305: All code that currently beeps should use visual bell instead Stefan Kangas
@ 2021-04-17 7:03 ` Eli Zaretskii
2021-04-17 11:54 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-17 7:03 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, 1305, monnier
> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 6:06 ` bug#1305: All code that currently beeps should use visual bell instead Stefan Kangas
2021-04-17 7:03 ` Eli Zaretskii
@ 2021-04-17 11:54 ` Lars Ingebrigtsen
2021-04-17 12:31 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-17 11:54 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, 1305, Stefan Monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 11:54 ` Lars Ingebrigtsen
@ 2021-04-17 12:31 ` Gregory Heytings
2021-04-17 12:39 ` Eli Zaretskii
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-17 12:31 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: jasonspiro4, 1305, Stefan Kangas, Stefan Monnier
[-- 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 --]
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 12:31 ` Gregory Heytings
@ 2021-04-17 12:39 ` Eli Zaretskii
2021-04-17 12:55 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-17 12:39 UTC (permalink / raw
To: Gregory Heytings; +Cc: larsi, 1305, stefan, jasonspiro4, monnier
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 12:39 ` Eli Zaretskii
@ 2021-04-17 12:55 ` Lars Ingebrigtsen
2021-04-17 13:07 ` Stefan Kangas
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-17 12:55 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Gregory Heytings, 1305, stefan, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 12:55 ` Lars Ingebrigtsen
@ 2021-04-17 13:07 ` Stefan Kangas
2021-04-17 13:13 ` Lars Ingebrigtsen
2021-04-17 13:16 ` Drew Adams
2021-04-17 16:59 ` Dmitry Gutov
2 siblings, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-17 13:07 UTC (permalink / raw
To: Lars Ingebrigtsen, Eli Zaretskii
Cc: Gregory Heytings, 1305, jasonspiro4, monnier
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.)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:07 ` Stefan Kangas
@ 2021-04-17 13:13 ` Lars Ingebrigtsen
2021-04-17 13:32 ` Stefan Kangas
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-17 13:13 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 12:55 ` Lars Ingebrigtsen
2021-04-17 13:07 ` Stefan Kangas
@ 2021-04-17 13:16 ` Drew Adams
2021-04-17 16:59 ` Dmitry Gutov
2 siblings, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-17 13:16 UTC (permalink / raw
To: Lars Ingebrigtsen, Eli Zaretskii
Cc: Gregory Heytings, 1305@debbugs.gnu.org, stefan@marxist.se,
jasonspiro4@gmail.com, 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),
>
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:13 ` Lars Ingebrigtsen
@ 2021-04-17 13:32 ` Stefan Kangas
2021-04-17 13:39 ` Lars Ingebrigtsen
2021-04-17 19:17 ` Basil L. Contovounesios
2021-04-17 17:01 ` Dmitry Gutov
2021-04-17 20:59 ` Gregory Heytings
2 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-17 13:32 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:32 ` Stefan Kangas
@ 2021-04-17 13:39 ` Lars Ingebrigtsen
2021-04-17 14:05 ` Eli Zaretskii
2021-04-17 14:08 ` Stefan Kangas
2021-04-17 19:17 ` Basil L. Contovounesios
1 sibling, 2 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-17 13:39 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:39 ` Lars Ingebrigtsen
@ 2021-04-17 14:05 ` Eli Zaretskii
2021-04-17 14:08 ` Stefan Kangas
1 sibling, 0 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-17 14:05 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: gregory, 1305, stefan, jasonspiro4, monnier
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:39 ` Lars Ingebrigtsen
2021-04-17 14:05 ` Eli Zaretskii
@ 2021-04-17 14:08 ` Stefan Kangas
2021-04-18 10:41 ` Lars Ingebrigtsen
1 sibling, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-17 14:08 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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. :-)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 12:55 ` Lars Ingebrigtsen
2021-04-17 13:07 ` Stefan Kangas
2021-04-17 13:16 ` Drew Adams
@ 2021-04-17 16:59 ` Dmitry Gutov
2 siblings, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-17 16:59 UTC (permalink / raw
To: Lars Ingebrigtsen, Eli Zaretskii
Cc: Gregory Heytings, 1305, stefan, jasonspiro4, monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:13 ` Lars Ingebrigtsen
2021-04-17 13:32 ` Stefan Kangas
@ 2021-04-17 17:01 ` Dmitry Gutov
2021-04-17 20:59 ` Gregory Heytings
2 siblings, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-17 17:01 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Kangas
Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:32 ` Stefan Kangas
2021-04-17 13:39 ` Lars Ingebrigtsen
@ 2021-04-17 19:17 ` Basil L. Contovounesios
1 sibling, 0 replies; 180+ messages in thread
From: Basil L. Contovounesios @ 2021-04-17 19:17 UTC (permalink / raw
To: Stefan Kangas
Cc: Lars Ingebrigtsen, 1305, jasonspiro4, Gregory Heytings, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 13:13 ` Lars Ingebrigtsen
2021-04-17 13:32 ` Stefan Kangas
2021-04-17 17:01 ` Dmitry Gutov
@ 2021-04-17 20:59 ` Gregory Heytings
2021-04-17 21:09 ` Michael Welsh Duggan
2021-04-18 6:30 ` Eli Zaretskii
2 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-17 20:59 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: jasonspiro4, 1305, Stefan Kangas, monnier
>>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 20:59 ` Gregory Heytings
@ 2021-04-17 21:09 ` Michael Welsh Duggan
2021-04-17 21:17 ` Gregory Heytings
2021-04-18 6:30 ` Eli Zaretskii
1 sibling, 1 reply; 180+ messages in thread
From: Michael Welsh Duggan @ 2021-04-17 21:09 UTC (permalink / raw
To: Gregory Heytings
Cc: Lars Ingebrigtsen, 1305, Stefan Kangas, jasonspiro4, monnier
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)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 21:09 ` Michael Welsh Duggan
@ 2021-04-17 21:17 ` Gregory Heytings
2021-04-17 21:52 ` Michael Welsh Duggan
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-17 21:17 UTC (permalink / raw
To: Michael Welsh Duggan
Cc: Lars Ingebrigtsen, 1305, Stefan Kangas, jasonspiro4, monnier
>> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 21:17 ` Gregory Heytings
@ 2021-04-17 21:52 ` Michael Welsh Duggan
2021-04-17 22:04 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Michael Welsh Duggan @ 2021-04-17 21:52 UTC (permalink / raw
To: Gregory Heytings
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Lars Ingebrigtsen
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)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 21:52 ` Michael Welsh Duggan
@ 2021-04-17 22:04 ` Gregory Heytings
2021-04-17 23:30 ` bug#1305: [External] : " Drew Adams
2021-04-18 10:38 ` Lars Ingebrigtsen
0 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-17 22:04 UTC (permalink / raw
To: Michael Welsh Duggan
Cc: Lars Ingebrigtsen, 1305, Stefan Kangas, jasonspiro4, monnier
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 22:04 ` Gregory Heytings
@ 2021-04-17 23:30 ` Drew Adams
2021-04-18 10:38 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-17 23:30 UTC (permalink / raw
To: Gregory Heytings, Michael Welsh Duggan
Cc: Lars Ingebrigtsen, 1305@debbugs.gnu.org, Stefan Kangas,
jasonspiro4@gmail.com, monnier@iro.umontreal.ca
> 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.)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 20:59 ` Gregory Heytings
2021-04-17 21:09 ` Michael Welsh Duggan
@ 2021-04-18 6:30 ` Eli Zaretskii
2021-04-18 11:10 ` Gregory Heytings
2021-04-18 15:14 ` bug#1305: [External] : " Drew Adams
1 sibling, 2 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-18 6:30 UTC (permalink / raw
To: Gregory Heytings; +Cc: larsi, 1305, stefan, jasonspiro4, monnier
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 22:04 ` Gregory Heytings
2021-04-17 23:30 ` bug#1305: [External] : " Drew Adams
@ 2021-04-18 10:38 ` Lars Ingebrigtsen
2021-04-18 12:22 ` Stefan Kangas
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 10:38 UTC (permalink / raw
To: Gregory Heytings
Cc: Michael Welsh Duggan, jasonspiro4, 1305, Stefan Kangas, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-17 14:08 ` Stefan Kangas
@ 2021-04-18 10:41 ` Lars Ingebrigtsen
2021-04-18 12:22 ` Stefan Kangas
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 10:41 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 6:30 ` Eli Zaretskii
@ 2021-04-18 11:10 ` Gregory Heytings
2021-04-18 11:38 ` Eli Zaretskii
2021-04-18 15:14 ` bug#1305: [External] : " Drew Adams
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 11:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: larsi, 1305, stefan, jasonspiro4, monnier
>
> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 11:10 ` Gregory Heytings
@ 2021-04-18 11:38 ` Eli Zaretskii
0 siblings, 0 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-18 11:38 UTC (permalink / raw
To: Gregory Heytings; +Cc: larsi, 1305, stefan, jasonspiro4, monnier
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 10:41 ` Lars Ingebrigtsen
@ 2021-04-18 12:22 ` Stefan Kangas
2021-04-18 13:32 ` Gregory Heytings
2021-04-18 15:23 ` Lars Ingebrigtsen
0 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 12:22 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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.)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 10:38 ` Lars Ingebrigtsen
@ 2021-04-18 12:22 ` Stefan Kangas
2021-04-18 12:36 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 12:22 UTC (permalink / raw
To: Lars Ingebrigtsen, Gregory Heytings
Cc: Michael Welsh Duggan, jasonspiro4, 1305, monnier
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).
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:22 ` Stefan Kangas
@ 2021-04-18 12:36 ` Lars Ingebrigtsen
2021-04-18 13:10 ` Stefan Kangas
` (3 more replies)
0 siblings, 4 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 12:36 UTC (permalink / raw
To: Stefan Kangas
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:36 ` Lars Ingebrigtsen
@ 2021-04-18 13:10 ` Stefan Kangas
2021-04-18 13:15 ` Stefan Kangas
2021-04-18 15:22 ` Lars Ingebrigtsen
2021-04-18 15:06 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 13:10 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 13:10 ` Stefan Kangas
@ 2021-04-18 13:15 ` Stefan Kangas
2021-04-18 15:22 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 13:15 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:22 ` Stefan Kangas
@ 2021-04-18 13:32 ` Gregory Heytings
2021-04-18 15:23 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 13:32 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, Lars Ingebrigtsen, 1305, monnier
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:36 ` Lars Ingebrigtsen
2021-04-18 13:10 ` Stefan Kangas
@ 2021-04-18 15:06 ` Eli Zaretskii
2021-04-18 15:11 ` Lars Ingebrigtsen
2021-04-18 15:18 ` Dmitry Gutov
2021-04-18 15:26 ` Dmitry Gutov
2021-04-18 15:27 ` bug#1305: [External] : " Drew Adams
3 siblings, 2 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-18 15:06 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:06 ` Eli Zaretskii
@ 2021-04-18 15:11 ` Lars Ingebrigtsen
2021-04-18 15:23 ` Eli Zaretskii
` (2 more replies)
2021-04-18 15:18 ` Dmitry Gutov
1 sibling, 3 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 15:11 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 6:30 ` Eli Zaretskii
2021-04-18 11:10 ` Gregory Heytings
@ 2021-04-18 15:14 ` Drew Adams
1 sibling, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-18 15:14 UTC (permalink / raw
To: Eli Zaretskii, Gregory Heytings
Cc: larsi@gnus.org, 1305@debbugs.gnu.org, stefan@marxist.se,
jasonspiro4@gmail.com, monnier@iro.umontreal.ca
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:06 ` Eli Zaretskii
2021-04-18 15:11 ` Lars Ingebrigtsen
@ 2021-04-18 15:18 ` Dmitry Gutov
1 sibling, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-18 15:18 UTC (permalink / raw
To: Eli Zaretskii, Lars Ingebrigtsen
Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 13:10 ` Stefan Kangas
2021-04-18 13:15 ` Stefan Kangas
@ 2021-04-18 15:22 ` Lars Ingebrigtsen
2021-04-18 15:28 ` Stefan Monnier
2021-04-18 17:02 ` Gregory Heytings
1 sibling, 2 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 15:22 UTC (permalink / raw
To: Stefan Kangas
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:22 ` Stefan Kangas
2021-04-18 13:32 ` Gregory Heytings
@ 2021-04-18 15:23 ` Lars Ingebrigtsen
2021-04-18 15:42 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 15:23 UTC (permalink / raw
To: Stefan Kangas; +Cc: jasonspiro4, 1305, Gregory Heytings, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:11 ` Lars Ingebrigtsen
@ 2021-04-18 15:23 ` Eli Zaretskii
2021-04-18 15:35 ` Eli Zaretskii
2021-04-19 12:56 ` Lars Ingebrigtsen
2021-04-18 16:07 ` Andreas Schwab
2021-04-18 16:12 ` Stefan Kangas
2 siblings, 2 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-18 15:23 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:36 ` Lars Ingebrigtsen
2021-04-18 13:10 ` Stefan Kangas
2021-04-18 15:06 ` Eli Zaretskii
@ 2021-04-18 15:26 ` Dmitry Gutov
2021-04-18 15:37 ` Gregory Heytings
2021-04-18 16:27 ` Stefan Kangas
2021-04-18 15:27 ` bug#1305: [External] : " Drew Adams
3 siblings, 2 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-18 15:26 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Kangas
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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))))
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 12:36 ` Lars Ingebrigtsen
` (2 preceding siblings ...)
2021-04-18 15:26 ` Dmitry Gutov
@ 2021-04-18 15:27 ` Drew Adams
3 siblings, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-18 15:27 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Kangas
Cc: Michael Welsh Duggan, Gregory Heytings, 1305@debbugs.gnu.org,
jasonspiro4@gmail.com, monnier@iro.umontreal.ca
> > 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'...
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:22 ` Lars Ingebrigtsen
@ 2021-04-18 15:28 ` Stefan Monnier
2021-04-18 15:38 ` Lars Ingebrigtsen
2021-04-18 17:02 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Stefan Monnier @ 2021-04-18 15:28 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Kangas,
jasonspiro4
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:23 ` Eli Zaretskii
@ 2021-04-18 15:35 ` Eli Zaretskii
2021-04-19 12:56 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-18 15:35 UTC (permalink / raw
To: larsi; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:26 ` Dmitry Gutov
@ 2021-04-18 15:37 ` Gregory Heytings
2021-04-18 16:27 ` Stefan Kangas
1 sibling, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 15:37 UTC (permalink / raw
To: Dmitry Gutov
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Lars Ingebrigtsen
>
> 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)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:28 ` Stefan Monnier
@ 2021-04-18 15:38 ` Lars Ingebrigtsen
2021-04-18 18:34 ` Stefan Monnier
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-18 15:38 UTC (permalink / raw
To: Stefan Monnier
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Kangas,
jasonspiro4
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:23 ` Lars Ingebrigtsen
@ 2021-04-18 15:42 ` Gregory Heytings
0 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 15:42 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: jasonspiro4, 1305, Stefan Kangas, monnier
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:11 ` Lars Ingebrigtsen
2021-04-18 15:23 ` Eli Zaretskii
@ 2021-04-18 16:07 ` Andreas Schwab
2021-04-19 12:38 ` Lars Ingebrigtsen
2021-04-18 16:12 ` Stefan Kangas
2 siblings, 1 reply; 180+ messages in thread
From: Andreas Schwab @ 2021-04-18 16:07 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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."
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:11 ` Lars Ingebrigtsen
2021-04-18 15:23 ` Eli Zaretskii
2021-04-18 16:07 ` Andreas Schwab
@ 2021-04-18 16:12 ` Stefan Kangas
2021-04-18 16:20 ` Andreas Schwab
2021-04-19 12:39 ` Lars Ingebrigtsen
2 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 16:12 UTC (permalink / raw
To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: mwd, gregory, 1305, jasonspiro4, monnier
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).
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 16:12 ` Stefan Kangas
@ 2021-04-18 16:20 ` Andreas Schwab
2021-04-19 12:39 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Andreas Schwab @ 2021-04-18 16:20 UTC (permalink / raw
To: Stefan Kangas; +Cc: 1305, mwd, gregory, jasonspiro4, monnier, Lars Ingebrigtsen
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."
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:26 ` Dmitry Gutov
2021-04-18 15:37 ` Gregory Heytings
@ 2021-04-18 16:27 ` Stefan Kangas
2021-04-18 16:38 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 16:27 UTC (permalink / raw
To: Dmitry Gutov, Lars Ingebrigtsen
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 16:27 ` Stefan Kangas
@ 2021-04-18 16:38 ` Gregory Heytings
2021-04-18 17:05 ` Dmitry Gutov
2021-04-18 17:14 ` Stefan Kangas
0 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 16:38 UTC (permalink / raw
To: Stefan Kangas
Cc: 1305, Michael Welsh Duggan, jasonspiro4, monnier, Dmitry Gutov,
Lars Ingebrigtsen
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:22 ` Lars Ingebrigtsen
2021-04-18 15:28 ` Stefan Monnier
@ 2021-04-18 17:02 ` Gregory Heytings
2021-04-18 17:13 ` Eli Zaretskii
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 17:02 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, jasonspiro4, 1305, Stefan Kangas, monnier
[-- 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 16:38 ` Gregory Heytings
@ 2021-04-18 17:05 ` Dmitry Gutov
2021-04-18 17:14 ` Stefan Kangas
1 sibling, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-18 17:05 UTC (permalink / raw
To: Gregory Heytings, Stefan Kangas
Cc: Michael Welsh Duggan, Lars Ingebrigtsen, 1305, jasonspiro4,
monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 17:02 ` Gregory Heytings
@ 2021-04-18 17:13 ` Eli Zaretskii
2021-04-18 18:02 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-18 17:13 UTC (permalink / raw
To: Gregory Heytings; +Cc: 1305, mwd, stefan, jasonspiro4, monnier, larsi
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 16:38 ` Gregory Heytings
2021-04-18 17:05 ` Dmitry Gutov
@ 2021-04-18 17:14 ` Stefan Kangas
2021-04-19 12:33 ` Lars Ingebrigtsen
1 sibling, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 17:14 UTC (permalink / raw
To: Gregory Heytings
Cc: 1305, Michael Welsh Duggan, jasonspiro4, monnier, Dmitry Gutov,
Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 17:13 ` Eli Zaretskii
@ 2021-04-18 18:02 ` Gregory Heytings
2021-04-18 18:35 ` Stefan Kangas
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 18:02 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 1305, mwd, stefan, jasonspiro4, monnier, larsi
[-- 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:38 ` Lars Ingebrigtsen
@ 2021-04-18 18:34 ` Stefan Monnier
2021-04-19 12:37 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Monnier @ 2021-04-18 18:34 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Kangas,
jasonspiro4
>> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 18:02 ` Gregory Heytings
@ 2021-04-18 18:35 ` Stefan Kangas
2021-04-18 18:45 ` Gregory Heytings
2021-04-18 19:19 ` Gregory Heytings
0 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 18:35 UTC (permalink / raw
To: Gregory Heytings, Eli Zaretskii; +Cc: mwd, larsi, 1305, jasonspiro4, monnier
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.)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 18:35 ` Stefan Kangas
@ 2021-04-18 18:45 ` Gregory Heytings
2021-04-18 19:04 ` Stefan Kangas
2021-04-18 19:19 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 18:45 UTC (permalink / raw
To: Stefan Kangas; +Cc: 1305, mwd, jasonspiro4, monnier, larsi
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 18:45 ` Gregory Heytings
@ 2021-04-18 19:04 ` Stefan Kangas
0 siblings, 0 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-18 19:04 UTC (permalink / raw
To: Gregory Heytings; +Cc: 1305, mwd, jasonspiro4, monnier, larsi
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 18:35 ` Stefan Kangas
2021-04-18 18:45 ` Gregory Heytings
@ 2021-04-18 19:19 ` Gregory Heytings
1 sibling, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-18 19:19 UTC (permalink / raw
To: Stefan Kangas; +Cc: 1305, mwd, jasonspiro4, monnier, larsi
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 17:14 ` Stefan Kangas
@ 2021-04-19 12:33 ` Lars Ingebrigtsen
2021-04-19 12:40 ` Dmitry Gutov
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:33 UTC (permalink / raw
To: Stefan Kangas
Cc: 1305, Michael Welsh Duggan, Gregory Heytings, jasonspiro4,
monnier, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 18:34 ` Stefan Monnier
@ 2021-04-19 12:37 ` Lars Ingebrigtsen
2021-04-19 13:04 ` Dmitry Gutov
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:37 UTC (permalink / raw
To: Stefan Monnier
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Kangas,
jasonspiro4
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 16:07 ` Andreas Schwab
@ 2021-04-19 12:38 ` Lars Ingebrigtsen
0 siblings, 0 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:38 UTC (permalink / raw
To: Andreas Schwab; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 16:12 ` Stefan Kangas
2021-04-18 16:20 ` Andreas Schwab
@ 2021-04-19 12:39 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:39 UTC (permalink / raw
To: Stefan Kangas; +Cc: 1305, mwd, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:33 ` Lars Ingebrigtsen
@ 2021-04-19 12:40 ` Dmitry Gutov
2021-04-19 12:47 ` Gregory Heytings
2021-04-19 12:51 ` Lars Ingebrigtsen
0 siblings, 2 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-19 12:40 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Kangas
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4,
monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:40 ` Dmitry Gutov
@ 2021-04-19 12:47 ` Gregory Heytings
2021-04-19 13:01 ` Dmitry Gutov
2021-04-19 12:51 ` Lars Ingebrigtsen
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-19 12:47 UTC (permalink / raw
To: Dmitry Gutov
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Lars Ingebrigtsen
[-- 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 --]
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:40 ` Dmitry Gutov
2021-04-19 12:47 ` Gregory Heytings
@ 2021-04-19 12:51 ` Lars Ingebrigtsen
2021-04-19 14:03 ` Stefan Monnier
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:51 UTC (permalink / raw
To: Dmitry Gutov
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, Gregory Heytings,
jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-18 15:23 ` Eli Zaretskii
2021-04-18 15:35 ` Eli Zaretskii
@ 2021-04-19 12:56 ` Lars Ingebrigtsen
2021-04-19 13:12 ` Eli Zaretskii
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-19 12:56 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:47 ` Gregory Heytings
@ 2021-04-19 13:01 ` Dmitry Gutov
2021-04-19 13:16 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-19 13:01 UTC (permalink / raw
To: Gregory Heytings
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:37 ` Lars Ingebrigtsen
@ 2021-04-19 13:04 ` Dmitry Gutov
2021-04-19 13:26 ` Stefan Kangas
2021-04-19 13:30 ` Gregory Heytings
2 siblings, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-19 13:04 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Monnier
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Kangas,
jasonspiro4
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:56 ` Lars Ingebrigtsen
@ 2021-04-19 13:12 ` Eli Zaretskii
2021-04-25 18:03 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-19 13:12 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 13:01 ` Dmitry Gutov
@ 2021-04-19 13:16 ` Gregory Heytings
2021-04-19 13:26 ` Stefan Kangas
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-19 13:16 UTC (permalink / raw
To: Dmitry Gutov
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Lars Ingebrigtsen
>
> '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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:37 ` Lars Ingebrigtsen
2021-04-19 13:04 ` Dmitry Gutov
@ 2021-04-19 13:26 ` Stefan Kangas
2021-04-25 18:06 ` Lars Ingebrigtsen
2021-04-19 13:30 ` Gregory Heytings
2 siblings, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-19 13:26 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Monnier
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, jasonspiro4
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 13:16 ` Gregory Heytings
@ 2021-04-19 13:26 ` Stefan Kangas
2021-04-19 13:37 ` Dmitry Gutov
2021-04-19 14:41 ` Alan Third
2 siblings, 0 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-19 13:26 UTC (permalink / raw
To: Gregory Heytings, Dmitry Gutov
Cc: Michael Welsh Duggan, Lars Ingebrigtsen, 1305, jasonspiro4,
monnier
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:37 ` Lars Ingebrigtsen
2021-04-19 13:04 ` Dmitry Gutov
2021-04-19 13:26 ` Stefan Kangas
@ 2021-04-19 13:30 ` Gregory Heytings
2 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-19 13:30 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, jasonspiro4, 1305, Stefan Kangas,
Stefan Monnier
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 13:16 ` Gregory Heytings
2021-04-19 13:26 ` Stefan Kangas
@ 2021-04-19 13:37 ` Dmitry Gutov
2021-04-19 14:41 ` Alan Third
2 siblings, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-19 13:37 UTC (permalink / raw
To: Gregory Heytings
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 12:51 ` Lars Ingebrigtsen
@ 2021-04-19 14:03 ` Stefan Monnier
0 siblings, 0 replies; 180+ messages in thread
From: Stefan Monnier @ 2021-04-19 14:03 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, Gregory Heytings,
jasonspiro4, Dmitry Gutov
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 13:16 ` Gregory Heytings
2021-04-19 13:26 ` Stefan Kangas
2021-04-19 13:37 ` Dmitry Gutov
@ 2021-04-19 14:41 ` Alan Third
2021-04-20 14:21 ` Gregory Heytings
2 siblings, 1 reply; 180+ messages in thread
From: Alan Third @ 2021-04-19 14:41 UTC (permalink / raw
To: Gregory Heytings
Cc: 1305, Michael Welsh Duggan, Stefan Kangas, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 14:41 ` Alan Third
@ 2021-04-20 14:21 ` Gregory Heytings
2021-04-20 18:27 ` Dmitry Gutov
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-20 14:21 UTC (permalink / raw
To: 1305
Cc: Alan Third, Michael Welsh Duggan, Stefan Kangas, jasonspiro4,
monnier, Dmitry Gutov, Lars Ingebrigtsen
[-- 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
^ permalink raw reply related [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-20 14:21 ` Gregory Heytings
@ 2021-04-20 18:27 ` Dmitry Gutov
2021-04-20 19:19 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-20 18:27 UTC (permalink / raw
To: Gregory Heytings, 1305
Cc: Alan Third, Michael Welsh Duggan, Stefan Kangas, jasonspiro4,
monnier, Lars Ingebrigtsen
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-20 18:27 ` Dmitry Gutov
@ 2021-04-20 19:19 ` Gregory Heytings
2021-04-21 1:16 ` Dmitry Gutov
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-20 19:19 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, monnier, Lars Ingebrigtsen
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-20 19:19 ` Gregory Heytings
@ 2021-04-21 1:16 ` Dmitry Gutov
2021-04-21 6:47 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-21 1:16 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 1:16 ` Dmitry Gutov
@ 2021-04-21 6:47 ` Gregory Heytings
2021-04-21 13:11 ` Stefan Kangas
2021-04-21 14:45 ` Dmitry Gutov
0 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 6:47 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, monnier, Lars Ingebrigtsen
[-- 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
^ permalink raw reply related [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 6:47 ` Gregory Heytings
@ 2021-04-21 13:11 ` Stefan Kangas
2021-04-21 14:05 ` Gregory Heytings
` (2 more replies)
2021-04-21 14:45 ` Dmitry Gutov
1 sibling, 3 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-21 13:11 UTC (permalink / raw
To: Gregory Heytings, Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Lars Ingebrigtsen
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 13:11 ` Stefan Kangas
@ 2021-04-21 14:05 ` Gregory Heytings
2021-04-21 14:12 ` Dmitry Gutov
2021-04-21 14:30 ` Stefan Kangas
2021-04-21 14:33 ` Stefan Monnier
2021-04-21 15:08 ` Dmitry Gutov
2 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 14:05 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
>>> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:05 ` Gregory Heytings
@ 2021-04-21 14:12 ` Dmitry Gutov
2021-04-21 14:30 ` Stefan Kangas
1 sibling, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-21 14:12 UTC (permalink / raw
To: Gregory Heytings, Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:05 ` Gregory Heytings
2021-04-21 14:12 ` Dmitry Gutov
@ 2021-04-21 14:30 ` Stefan Kangas
2021-04-21 14:35 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-21 14:30 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 13:11 ` Stefan Kangas
2021-04-21 14:05 ` Gregory Heytings
@ 2021-04-21 14:33 ` Stefan Monnier
2021-04-21 14:51 ` Dmitry Gutov
2021-04-25 18:12 ` Lars Ingebrigtsen
2021-04-21 15:08 ` Dmitry Gutov
2 siblings, 2 replies; 180+ messages in thread
From: Stefan Monnier @ 2021-04-21 14:33 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Gregory Heytings, Dmitry Gutov, Lars Ingebrigtsen
>> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:30 ` Stefan Kangas
@ 2021-04-21 14:35 ` Gregory Heytings
2021-04-21 14:45 ` Stefan Kangas
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 14:35 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
>>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 6:47 ` Gregory Heytings
2021-04-21 13:11 ` Stefan Kangas
@ 2021-04-21 14:45 ` Dmitry Gutov
2021-04-21 16:01 ` Gregory Heytings
2021-04-21 20:22 ` Gregory Heytings
1 sibling, 2 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-21 14:45 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:35 ` Gregory Heytings
@ 2021-04-21 14:45 ` Stefan Kangas
2021-04-21 14:53 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-21 14:45 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:33 ` Stefan Monnier
@ 2021-04-21 14:51 ` Dmitry Gutov
2021-04-21 15:14 ` Stefan Monnier
2021-04-25 18:12 ` Lars Ingebrigtsen
1 sibling, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-21 14:51 UTC (permalink / raw
To: Stefan Monnier, Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, Gregory Heytings,
jasonspiro4, Lars Ingebrigtsen
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:45 ` Stefan Kangas
@ 2021-04-21 14:53 ` Gregory Heytings
2021-04-21 21:27 ` Stefan Kangas
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 14:53 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
[-- 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
^ permalink raw reply related [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 13:11 ` Stefan Kangas
2021-04-21 14:05 ` Gregory Heytings
2021-04-21 14:33 ` Stefan Monnier
@ 2021-04-21 15:08 ` Dmitry Gutov
2021-04-21 15:18 ` Stefan Monnier
2 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-21 15:08 UTC (permalink / raw
To: Stefan Kangas, Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:51 ` Dmitry Gutov
@ 2021-04-21 15:14 ` Stefan Monnier
0 siblings, 0 replies; 180+ messages in thread
From: Stefan Monnier @ 2021-04-21 15:14 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
Gregory Heytings, jasonspiro4, Lars Ingebrigtsen
>>> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 15:08 ` Dmitry Gutov
@ 2021-04-21 15:18 ` Stefan Monnier
2021-04-21 16:14 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Monnier @ 2021-04-21 15:18 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
Gregory Heytings, jasonspiro4, Lars Ingebrigtsen
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:45 ` Dmitry Gutov
@ 2021-04-21 16:01 ` Gregory Heytings
2021-04-21 17:34 ` Eli Zaretskii
2021-04-21 20:22 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 16:01 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, monnier, Lars Ingebrigtsen
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 15:18 ` Stefan Monnier
@ 2021-04-21 16:14 ` Gregory Heytings
2021-04-21 17:27 ` Stefan Monnier
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 16:14 UTC (permalink / raw
To: Stefan Monnier
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Dmitry Gutov, Lars Ingebrigtsen
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 16:14 ` Gregory Heytings
@ 2021-04-21 17:27 ` Stefan Monnier
2021-04-21 20:26 ` Gregory Heytings
2021-04-21 22:03 ` bug#1305: [External] : " Drew Adams
0 siblings, 2 replies; 180+ messages in thread
From: Stefan Monnier @ 2021-04-21 17:27 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Dmitry Gutov, Lars Ingebrigtsen
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 16:01 ` Gregory Heytings
@ 2021-04-21 17:34 ` Eli Zaretskii
0 siblings, 0 replies; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-21 17:34 UTC (permalink / raw
To: Gregory Heytings
Cc: alan, 1305, mwd, stefan, jasonspiro4, monnier, dgutov, larsi
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:45 ` Dmitry Gutov
2021-04-21 16:01 ` Gregory Heytings
@ 2021-04-21 20:22 ` Gregory Heytings
1 sibling, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 20:22 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, monnier, Lars Ingebrigtsen
[-- 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 17:27 ` Stefan Monnier
@ 2021-04-21 20:26 ` Gregory Heytings
2021-04-21 22:03 ` bug#1305: [External] : " Drew Adams
1 sibling, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-21 20:26 UTC (permalink / raw
To: Stefan Monnier
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Dmitry Gutov, Lars Ingebrigtsen
>
> 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 ;-)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:53 ` Gregory Heytings
@ 2021-04-21 21:27 ` Stefan Kangas
0 siblings, 0 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-21 21:27 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4, monnier,
Dmitry Gutov, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 17:27 ` Stefan Monnier
2021-04-21 20:26 ` Gregory Heytings
@ 2021-04-21 22:03 ` Drew Adams
1 sibling, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-21 22:03 UTC (permalink / raw
To: Stefan Monnier, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Dmitry Gutov,
Lars Ingebrigtsen
> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 13:12 ` Eli Zaretskii
@ 2021-04-25 18:03 ` Lars Ingebrigtsen
2021-04-25 18:52 ` Andreas Schwab
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-25 18:03 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-19 13:26 ` Stefan Kangas
@ 2021-04-25 18:06 ` Lars Ingebrigtsen
2021-04-25 20:06 ` Stefan Kangas
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-25 18:06 UTC (permalink / raw
To: Stefan Kangas
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Monnier,
jasonspiro4
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-21 14:33 ` Stefan Monnier
2021-04-21 14:51 ` Dmitry Gutov
@ 2021-04-25 18:12 ` Lars Ingebrigtsen
2021-04-25 21:03 ` Stefan Monnier
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-25 18:12 UTC (permalink / raw
To: Stefan Monnier
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
Gregory Heytings, jasonspiro4, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 18:03 ` Lars Ingebrigtsen
@ 2021-04-25 18:52 ` Andreas Schwab
2021-04-25 19:01 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Andreas Schwab @ 2021-04-25 18:52 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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."
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 18:52 ` Andreas Schwab
@ 2021-04-25 19:01 ` Lars Ingebrigtsen
2021-04-25 19:18 ` Andreas Schwab
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-25 19:01 UTC (permalink / raw
To: Andreas Schwab; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 19:01 ` Lars Ingebrigtsen
@ 2021-04-25 19:18 ` Andreas Schwab
2021-04-25 19:33 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Andreas Schwab @ 2021-04-25 19:18 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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."
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 19:18 ` Andreas Schwab
@ 2021-04-25 19:33 ` Lars Ingebrigtsen
0 siblings, 0 replies; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-25 19:33 UTC (permalink / raw
To: Andreas Schwab; +Cc: 1305, mwd, stefan, gregory, jasonspiro4, monnier
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 18:06 ` Lars Ingebrigtsen
@ 2021-04-25 20:06 ` Stefan Kangas
0 siblings, 0 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-25 20:06 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Michael Welsh Duggan, Gregory Heytings, 1305, Stefan Monnier,
jasonspiro4
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 18:12 ` Lars Ingebrigtsen
@ 2021-04-25 21:03 ` Stefan Monnier
2021-04-27 1:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Monnier @ 2021-04-25 21:03 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
Gregory Heytings, jasonspiro4, Dmitry Gutov
>>> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-25 21:03 ` Stefan Monnier
@ 2021-04-27 1:07 ` Lars Ingebrigtsen
2021-04-27 9:54 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-27 1:07 UTC (permalink / raw
To: Stefan Monnier
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
Gregory Heytings, jasonspiro4, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-27 1:07 ` Lars Ingebrigtsen
@ 2021-04-27 9:54 ` Gregory Heytings
2021-04-27 15:15 ` bug#1305: [External] : " Drew Adams
2021-04-27 23:21 ` Lars Ingebrigtsen
0 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-27 9:54 UTC (permalink / raw
To: Lars Ingebrigtsen
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Dmitry Gutov
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-27 9:54 ` Gregory Heytings
@ 2021-04-27 15:15 ` Drew Adams
2021-04-27 23:21 ` Lars Ingebrigtsen
1 sibling, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-27 15:15 UTC (permalink / raw
To: Gregory Heytings, Lars Ingebrigtsen
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Dmitry Gutov
> >> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-27 9:54 ` Gregory Heytings
2021-04-27 15:15 ` bug#1305: [External] : " Drew Adams
@ 2021-04-27 23:21 ` Lars Ingebrigtsen
2021-04-28 10:08 ` Stefan Kangas
1 sibling, 1 reply; 180+ messages in thread
From: Lars Ingebrigtsen @ 2021-04-27 23:21 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-27 23:21 ` Lars Ingebrigtsen
@ 2021-04-28 10:08 ` Stefan Kangas
2021-04-28 13:12 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Stefan Kangas @ 2021-04-28 10:08 UTC (permalink / raw
To: Lars Ingebrigtsen, Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-28 10:08 ` Stefan Kangas
@ 2021-04-28 13:12 ` Gregory Heytings
2021-04-29 16:50 ` Dmitry Gutov
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-28 13:12 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Dmitry Gutov, Lars Ingebrigtsen
[-- 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
^ permalink raw reply related [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-28 13:12 ` Gregory Heytings
@ 2021-04-29 16:50 ` Dmitry Gutov
2021-04-29 19:48 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-29 16:50 UTC (permalink / raw
To: Gregory Heytings, Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Lars Ingebrigtsen
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 16:50 ` Dmitry Gutov
@ 2021-04-29 19:48 ` Gregory Heytings
2021-04-29 20:17 ` Dmitry Gutov
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-29 19:48 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 19:48 ` Gregory Heytings
@ 2021-04-29 20:17 ` Dmitry Gutov
2021-04-29 21:46 ` Gregory Heytings
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-29 20:17 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 20:17 ` Dmitry Gutov
@ 2021-04-29 21:46 ` Gregory Heytings
2021-04-29 23:23 ` Dmitry Gutov
2021-04-29 23:36 ` Stefan Monnier
2021-04-29 22:38 ` Stefan Kangas
2021-04-30 5:05 ` Eli Zaretskii
2 siblings, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-29 21:46 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
[-- 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 --]
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 20:17 ` Dmitry Gutov
2021-04-29 21:46 ` Gregory Heytings
@ 2021-04-29 22:38 ` Stefan Kangas
2021-04-29 23:11 ` Dmitry Gutov
2021-04-30 6:58 ` Gregory Heytings
2021-04-30 5:05 ` Eli Zaretskii
2 siblings, 2 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-04-29 22:38 UTC (permalink / raw
To: Dmitry Gutov, Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 22:38 ` Stefan Kangas
@ 2021-04-29 23:11 ` Dmitry Gutov
2021-04-30 6:58 ` Gregory Heytings
1 sibling, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-29 23:11 UTC (permalink / raw
To: Stefan Kangas, Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Lars Ingebrigtsen
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 21:46 ` Gregory Heytings
@ 2021-04-29 23:23 ` Dmitry Gutov
2021-04-29 23:35 ` bug#1305: [External] : " Drew Adams
2021-04-30 7:09 ` Gregory Heytings
2021-04-29 23:36 ` Stefan Monnier
1 sibling, 2 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-29 23:23 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 23:23 ` Dmitry Gutov
@ 2021-04-29 23:35 ` Drew Adams
2021-04-29 23:52 ` Dmitry Gutov
2021-05-01 7:50 ` Gregory Heytings
2021-04-30 7:09 ` Gregory Heytings
1 sibling, 2 replies; 180+ messages in thread
From: Drew Adams @ 2021-04-29 23:35 UTC (permalink / raw
To: Dmitry Gutov, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Lars Ingebrigtsen
> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 21:46 ` Gregory Heytings
2021-04-29 23:23 ` Dmitry Gutov
@ 2021-04-29 23:36 ` Stefan Monnier
2021-04-30 7:13 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Stefan Monnier @ 2021-04-29 23:36 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Dmitry Gutov, Lars Ingebrigtsen
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 23:35 ` bug#1305: [External] : " Drew Adams
@ 2021-04-29 23:52 ` Dmitry Gutov
2021-05-01 7:50 ` Gregory Heytings
1 sibling, 0 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-29 23:52 UTC (permalink / raw
To: Drew Adams, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Lars Ingebrigtsen
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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 20:17 ` Dmitry Gutov
2021-04-29 21:46 ` Gregory Heytings
2021-04-29 22:38 ` Stefan Kangas
@ 2021-04-30 5:05 ` Eli Zaretskii
2021-04-30 6:51 ` Gregory Heytings
2 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-30 5:05 UTC (permalink / raw
To: Dmitry Gutov
Cc: alan, 1305, mwd, stefan, gregory, jasonspiro4, monnier, larsi
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 5:05 ` Eli Zaretskii
@ 2021-04-30 6:51 ` Gregory Heytings
2021-04-30 7:06 ` Eli Zaretskii
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 6:51 UTC (permalink / raw
To: Eli Zaretskii
Cc: alan, 1305, mwd, stefan, jasonspiro4, monnier, Dmitry Gutov,
larsi
[-- 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 22:38 ` Stefan Kangas
2021-04-29 23:11 ` Dmitry Gutov
@ 2021-04-30 6:58 ` Gregory Heytings
2021-04-30 13:08 ` Gregory Heytings
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 6:58 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Dmitry Gutov, Lars Ingebrigtsen
[-- 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 6:51 ` Gregory Heytings
@ 2021-04-30 7:06 ` Eli Zaretskii
2021-04-30 7:27 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-30 7:06 UTC (permalink / raw
To: Gregory Heytings
Cc: alan, 1305, mwd, stefan, jasonspiro4, monnier, dgutov, larsi
> 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.)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 23:23 ` Dmitry Gutov
2021-04-29 23:35 ` bug#1305: [External] : " Drew Adams
@ 2021-04-30 7:09 ` Gregory Heytings
2021-04-30 22:22 ` Dmitry Gutov
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 7:09 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
[-- 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 23:36 ` Stefan Monnier
@ 2021-04-30 7:13 ` Gregory Heytings
0 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 7:13 UTC (permalink / raw
To: Stefan Monnier
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Dmitry Gutov, Lars Ingebrigtsen
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 7:06 ` Eli Zaretskii
@ 2021-04-30 7:27 ` Gregory Heytings
2021-04-30 8:03 ` Eli Zaretskii
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 7:27 UTC (permalink / raw
To: Eli Zaretskii
Cc: alan, 1305, mwd, stefan, jasonspiro4, monnier, dgutov, larsi
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 7:27 ` Gregory Heytings
@ 2021-04-30 8:03 ` Eli Zaretskii
2021-04-30 8:41 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Eli Zaretskii @ 2021-04-30 8:03 UTC (permalink / raw
To: Gregory Heytings
Cc: alan, 1305, mwd, stefan, jasonspiro4, monnier, dgutov, larsi
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 8:03 ` Eli Zaretskii
@ 2021-04-30 8:41 ` Gregory Heytings
0 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 8:41 UTC (permalink / raw
To: Eli Zaretskii
Cc: alan, 1305, mwd, stefan, jasonspiro4, monnier, dgutov, larsi
>> "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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 6:58 ` Gregory Heytings
@ 2021-04-30 13:08 ` Gregory Heytings
0 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 13:08 UTC (permalink / raw
To: Stefan Kangas
Cc: Alan Third, 1305, Michael Welsh Duggan, jasonspiro4,
Stefan Monnier, Dmitry Gutov, Lars Ingebrigtsen
[-- 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 --]
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 7:09 ` Gregory Heytings
@ 2021-04-30 22:22 ` Dmitry Gutov
2021-04-30 23:19 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-30 22:22 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 22:22 ` Dmitry Gutov
@ 2021-04-30 23:19 ` Gregory Heytings
2021-04-30 23:28 ` Dmitry Gutov
0 siblings, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-04-30 23:19 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
>> 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?
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 23:19 ` Gregory Heytings
@ 2021-04-30 23:28 ` Dmitry Gutov
2021-05-01 0:00 ` Gregory Heytings
2021-05-01 0:05 ` bug#1305: [External] : " Drew Adams
0 siblings, 2 replies; 180+ messages in thread
From: Dmitry Gutov @ 2021-04-30 23:28 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 23:28 ` Dmitry Gutov
@ 2021-05-01 0:00 ` Gregory Heytings
2021-05-01 0:57 ` Dmitry Gutov
2021-05-01 0:05 ` bug#1305: [External] : " Drew Adams
1 sibling, 1 reply; 180+ messages in thread
From: Gregory Heytings @ 2021-05-01 0:00 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-30 23:28 ` Dmitry Gutov
2021-05-01 0:00 ` Gregory Heytings
@ 2021-05-01 0:05 ` Drew Adams
2021-05-01 1:08 ` Dmitry Gutov
1 sibling, 1 reply; 180+ messages in thread
From: Drew Adams @ 2021-05-01 0:05 UTC (permalink / raw
To: Dmitry Gutov, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Lars Ingebrigtsen
> > 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 0:00 ` Gregory Heytings
@ 2021-05-01 0:57 ` Dmitry Gutov
2021-05-01 7:50 ` Gregory Heytings
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-05-01 0:57 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 0:05 ` bug#1305: [External] : " Drew Adams
@ 2021-05-01 1:08 ` Dmitry Gutov
2021-05-01 2:05 ` Drew Adams
0 siblings, 1 reply; 180+ messages in thread
From: Dmitry Gutov @ 2021-05-01 1:08 UTC (permalink / raw
To: Drew Adams, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Lars Ingebrigtsen
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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 1:08 ` Dmitry Gutov
@ 2021-05-01 2:05 ` Drew Adams
0 siblings, 0 replies; 180+ messages in thread
From: Drew Adams @ 2021-05-01 2:05 UTC (permalink / raw
To: Dmitry Gutov, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Lars Ingebrigtsen
> > 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 0:57 ` Dmitry Gutov
@ 2021-05-01 7:50 ` Gregory Heytings
0 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-05-01 7:50 UTC (permalink / raw
To: Dmitry Gutov
Cc: Alan Third, 1305, Michael Welsh Duggan, Stefan Kangas,
jasonspiro4, Stefan Monnier, Lars Ingebrigtsen
>> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-04-29 23:35 ` bug#1305: [External] : " Drew Adams
2021-04-29 23:52 ` Dmitry Gutov
@ 2021-05-01 7:50 ` Gregory Heytings
2021-05-01 14:13 ` Drew Adams
2021-05-01 14:28 ` Stefan Monnier
1 sibling, 2 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-05-01 7:50 UTC (permalink / raw
To: Drew Adams
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Dmitry Gutov, Lars Ingebrigtsen
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 7:50 ` Gregory Heytings
@ 2021-05-01 14:13 ` Drew Adams
2021-05-01 16:55 ` Gregory Heytings
2021-05-01 14:28 ` Stefan Monnier
1 sibling, 1 reply; 180+ messages in thread
From: Drew Adams @ 2021-05-01 14:13 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Dmitry Gutov, Lars Ingebrigtsen
> > 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 7:50 ` Gregory Heytings
2021-05-01 14:13 ` Drew Adams
@ 2021-05-01 14:28 ` Stefan Monnier
2021-05-01 16:48 ` Gregory Heytings
2021-05-02 10:44 ` Stefan Kangas
1 sibling, 2 replies; 180+ messages in thread
From: Stefan Monnier @ 2021-05-01 14:28 UTC (permalink / raw
To: Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Dmitry Gutov,
Lars Ingebrigtsen
> 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
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 14:28 ` Stefan Monnier
@ 2021-05-01 16:48 ` Gregory Heytings
2021-05-02 10:44 ` Stefan Kangas
1 sibling, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-05-01 16:48 UTC (permalink / raw
To: Stefan Monnier
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Dmitry Gutov,
Lars Ingebrigtsen
>> 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 ;-)
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 14:13 ` Drew Adams
@ 2021-05-01 16:55 ` Gregory Heytings
0 siblings, 0 replies; 180+ messages in thread
From: Gregory Heytings @ 2021-05-01 16:55 UTC (permalink / raw
To: Drew Adams
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
Stefan Kangas, jasonspiro4@gmail.com, Stefan Monnier,
Dmitry Gutov, Lars Ingebrigtsen
>
> 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.
^ permalink raw reply [flat|nested] 180+ messages in thread
* bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead
2021-05-01 14:28 ` Stefan Monnier
2021-05-01 16:48 ` Gregory Heytings
@ 2021-05-02 10:44 ` Stefan Kangas
1 sibling, 0 replies; 180+ messages in thread
From: Stefan Kangas @ 2021-05-02 10:44 UTC (permalink / raw
To: Stefan Monnier, Gregory Heytings
Cc: Alan Third, 1305@debbugs.gnu.org, Michael Welsh Duggan,
jasonspiro4@gmail.com, Dmitry Gutov, Lars Ingebrigtsen
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. ;-))
^ permalink raw reply [flat|nested] 180+ messages in thread
end of thread, other threads:[~2021-05-02 10:44 UTC | newest]
Thread overview: 180+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-09 1:50 bug#1305: All code that currently beeps should use visual bell instead Jason Spiro
2008-11-09 2:00 ` Processed: " Emacs bug Tracking System
2008-11-09 3:57 ` bug#1305: All code that currently beeps should use visual bellinstead Drew Adams
2008-11-09 4:08 ` Jason Spiro
2008-11-09 19:17 ` Eli Zaretskii
2008-11-09 19:04 ` Eli Zaretskii
2008-11-09 19:19 ` Drew Adams
2008-11-09 20:00 ` Eli Zaretskii
2008-11-10 2:07 ` Stefan Monnier
2008-11-10 6:28 ` Drew Adams
2008-11-11 21:20 ` bug#1305: All code that currently beeps should usevisual bellinstead Drew Adams
2008-11-10 8:34 ` bug#1305: All code that currently beeps should use visual bellinstead Lennart Borgman
2008-11-10 15:22 ` Stefan Monnier
2008-11-10 16:58 ` Lennart Borgman
2008-11-11 18:38 ` Jason A. Spiro
2008-11-10 22:17 ` Richard M. Stallman
2008-11-11 18:50 ` Jason Spiro
2008-11-12 3:33 ` Richard M. Stallman
2008-11-13 7:41 ` Jason Spiro
2021-04-17 6:06 ` bug#1305: All code that currently beeps should use visual bell instead Stefan Kangas
2021-04-17 7:03 ` Eli Zaretskii
2021-04-17 11:54 ` Lars Ingebrigtsen
2021-04-17 12:31 ` Gregory Heytings
2021-04-17 12:39 ` Eli Zaretskii
2021-04-17 12:55 ` Lars Ingebrigtsen
2021-04-17 13:07 ` Stefan Kangas
2021-04-17 13:13 ` Lars Ingebrigtsen
2021-04-17 13:32 ` Stefan Kangas
2021-04-17 13:39 ` Lars Ingebrigtsen
2021-04-17 14:05 ` Eli Zaretskii
2021-04-17 14:08 ` Stefan Kangas
2021-04-18 10:41 ` Lars Ingebrigtsen
2021-04-18 12:22 ` Stefan Kangas
2021-04-18 13:32 ` Gregory Heytings
2021-04-18 15:23 ` Lars Ingebrigtsen
2021-04-18 15:42 ` Gregory Heytings
2021-04-17 19:17 ` Basil L. Contovounesios
2021-04-17 17:01 ` Dmitry Gutov
2021-04-17 20:59 ` Gregory Heytings
2021-04-17 21:09 ` Michael Welsh Duggan
2021-04-17 21:17 ` Gregory Heytings
2021-04-17 21:52 ` Michael Welsh Duggan
2021-04-17 22:04 ` Gregory Heytings
2021-04-17 23:30 ` bug#1305: [External] : " Drew Adams
2021-04-18 10:38 ` Lars Ingebrigtsen
2021-04-18 12:22 ` Stefan Kangas
2021-04-18 12:36 ` Lars Ingebrigtsen
2021-04-18 13:10 ` Stefan Kangas
2021-04-18 13:15 ` Stefan Kangas
2021-04-18 15:22 ` Lars Ingebrigtsen
2021-04-18 15:28 ` Stefan Monnier
2021-04-18 15:38 ` Lars Ingebrigtsen
2021-04-18 18:34 ` Stefan Monnier
2021-04-19 12:37 ` Lars Ingebrigtsen
2021-04-19 13:04 ` Dmitry Gutov
2021-04-19 13:26 ` Stefan Kangas
2021-04-25 18:06 ` Lars Ingebrigtsen
2021-04-25 20:06 ` Stefan Kangas
2021-04-19 13:30 ` Gregory Heytings
2021-04-18 17:02 ` Gregory Heytings
2021-04-18 17:13 ` Eli Zaretskii
2021-04-18 18:02 ` Gregory Heytings
2021-04-18 18:35 ` Stefan Kangas
2021-04-18 18:45 ` Gregory Heytings
2021-04-18 19:04 ` Stefan Kangas
2021-04-18 19:19 ` Gregory Heytings
2021-04-18 15:06 ` Eli Zaretskii
2021-04-18 15:11 ` Lars Ingebrigtsen
2021-04-18 15:23 ` Eli Zaretskii
2021-04-18 15:35 ` Eli Zaretskii
2021-04-19 12:56 ` Lars Ingebrigtsen
2021-04-19 13:12 ` Eli Zaretskii
2021-04-25 18:03 ` Lars Ingebrigtsen
2021-04-25 18:52 ` Andreas Schwab
2021-04-25 19:01 ` Lars Ingebrigtsen
2021-04-25 19:18 ` Andreas Schwab
2021-04-25 19:33 ` Lars Ingebrigtsen
2021-04-18 16:07 ` Andreas Schwab
2021-04-19 12:38 ` Lars Ingebrigtsen
2021-04-18 16:12 ` Stefan Kangas
2021-04-18 16:20 ` Andreas Schwab
2021-04-19 12:39 ` Lars Ingebrigtsen
2021-04-18 15:18 ` Dmitry Gutov
2021-04-18 15:26 ` Dmitry Gutov
2021-04-18 15:37 ` Gregory Heytings
2021-04-18 16:27 ` Stefan Kangas
2021-04-18 16:38 ` Gregory Heytings
2021-04-18 17:05 ` Dmitry Gutov
2021-04-18 17:14 ` Stefan Kangas
2021-04-19 12:33 ` Lars Ingebrigtsen
2021-04-19 12:40 ` Dmitry Gutov
2021-04-19 12:47 ` Gregory Heytings
2021-04-19 13:01 ` Dmitry Gutov
2021-04-19 13:16 ` Gregory Heytings
2021-04-19 13:26 ` Stefan Kangas
2021-04-19 13:37 ` Dmitry Gutov
2021-04-19 14:41 ` Alan Third
2021-04-20 14:21 ` Gregory Heytings
2021-04-20 18:27 ` Dmitry Gutov
2021-04-20 19:19 ` Gregory Heytings
2021-04-21 1:16 ` Dmitry Gutov
2021-04-21 6:47 ` Gregory Heytings
2021-04-21 13:11 ` Stefan Kangas
2021-04-21 14:05 ` Gregory Heytings
2021-04-21 14:12 ` Dmitry Gutov
2021-04-21 14:30 ` Stefan Kangas
2021-04-21 14:35 ` Gregory Heytings
2021-04-21 14:45 ` Stefan Kangas
2021-04-21 14:53 ` Gregory Heytings
2021-04-21 21:27 ` Stefan Kangas
2021-04-21 14:33 ` Stefan Monnier
2021-04-21 14:51 ` Dmitry Gutov
2021-04-21 15:14 ` Stefan Monnier
2021-04-25 18:12 ` Lars Ingebrigtsen
2021-04-25 21:03 ` Stefan Monnier
2021-04-27 1:07 ` Lars Ingebrigtsen
2021-04-27 9:54 ` Gregory Heytings
2021-04-27 15:15 ` bug#1305: [External] : " Drew Adams
2021-04-27 23:21 ` Lars Ingebrigtsen
2021-04-28 10:08 ` Stefan Kangas
2021-04-28 13:12 ` Gregory Heytings
2021-04-29 16:50 ` Dmitry Gutov
2021-04-29 19:48 ` Gregory Heytings
2021-04-29 20:17 ` Dmitry Gutov
2021-04-29 21:46 ` Gregory Heytings
2021-04-29 23:23 ` Dmitry Gutov
2021-04-29 23:35 ` bug#1305: [External] : " Drew Adams
2021-04-29 23:52 ` Dmitry Gutov
2021-05-01 7:50 ` Gregory Heytings
2021-05-01 14:13 ` Drew Adams
2021-05-01 16:55 ` Gregory Heytings
2021-05-01 14:28 ` Stefan Monnier
2021-05-01 16:48 ` Gregory Heytings
2021-05-02 10:44 ` Stefan Kangas
2021-04-30 7:09 ` Gregory Heytings
2021-04-30 22:22 ` Dmitry Gutov
2021-04-30 23:19 ` Gregory Heytings
2021-04-30 23:28 ` Dmitry Gutov
2021-05-01 0:00 ` Gregory Heytings
2021-05-01 0:57 ` Dmitry Gutov
2021-05-01 7:50 ` Gregory Heytings
2021-05-01 0:05 ` bug#1305: [External] : " Drew Adams
2021-05-01 1:08 ` Dmitry Gutov
2021-05-01 2:05 ` Drew Adams
2021-04-29 23:36 ` Stefan Monnier
2021-04-30 7:13 ` Gregory Heytings
2021-04-29 22:38 ` Stefan Kangas
2021-04-29 23:11 ` Dmitry Gutov
2021-04-30 6:58 ` Gregory Heytings
2021-04-30 13:08 ` Gregory Heytings
2021-04-30 5:05 ` Eli Zaretskii
2021-04-30 6:51 ` Gregory Heytings
2021-04-30 7:06 ` Eli Zaretskii
2021-04-30 7:27 ` Gregory Heytings
2021-04-30 8:03 ` Eli Zaretskii
2021-04-30 8:41 ` Gregory Heytings
2021-04-21 15:08 ` Dmitry Gutov
2021-04-21 15:18 ` Stefan Monnier
2021-04-21 16:14 ` Gregory Heytings
2021-04-21 17:27 ` Stefan Monnier
2021-04-21 20:26 ` Gregory Heytings
2021-04-21 22:03 ` bug#1305: [External] : " Drew Adams
2021-04-21 14:45 ` Dmitry Gutov
2021-04-21 16:01 ` Gregory Heytings
2021-04-21 17:34 ` Eli Zaretskii
2021-04-21 20:22 ` Gregory Heytings
2021-04-19 12:51 ` Lars Ingebrigtsen
2021-04-19 14:03 ` Stefan Monnier
2021-04-18 15:27 ` bug#1305: [External] : " Drew Adams
2021-04-18 6:30 ` Eli Zaretskii
2021-04-18 11:10 ` Gregory Heytings
2021-04-18 11:38 ` Eli Zaretskii
2021-04-18 15:14 ` bug#1305: [External] : " Drew Adams
2021-04-17 13:16 ` Drew Adams
2021-04-17 16:59 ` Dmitry Gutov
2008-11-10 21:25 ` Xavier Maillard
-- strict thread matches above, loose matches on Subject: below --
2008-11-17 7:32 bug#1305: All code that currently beeps should use visual bellinstead Tim Connors
2008-11-17 7:37 ` Jason Spiro
2008-11-17 8:01 ` Sven Joachim
2008-11-17 14:52 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).