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.
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)
> 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.
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).
> 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.
> 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'.
> > 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.
> 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.
> 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
> > 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.
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.
> 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
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.
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
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".
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 .
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.
> 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.
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.
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?
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.
> 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?
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
[-- 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 --]
> 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.
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
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.)
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
> >> 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
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?
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
> 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.
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. :-)
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.
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.
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
>>> 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.
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)
>> 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?
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)
>
> 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.
> 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.)
> 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.
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
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
> > 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?
> 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.
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.)
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).
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
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.
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.
>
> 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.
> 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.
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
> 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.
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.
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
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
> 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?
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))))
> > 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'...
> 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
> 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?
> > 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)
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
>> 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.
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."
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).
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."
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.
>
> 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.
[-- 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
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.
> 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.
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.
[-- 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
>> 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
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.)
> > 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.
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.
>
> 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.
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
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
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
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
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.
[-- 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 --]
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
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
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.
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.
> 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.
> > '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.
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.
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.
>
> 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.
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.
> 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
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
[-- 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
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?
> > 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.
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.
[-- 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
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?
>>> 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?
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.
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.
>> 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
>>> 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.
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.
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?
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?
[-- 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
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.
>>> 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
> 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
>
> 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.
>> 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.
> 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
> 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.
[-- 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?
>
> 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 ;-)
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.
> 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?
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
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
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
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."
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
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."
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
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.
>>> 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
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
>> 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.
> >> 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?
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
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.
[-- 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
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?
>> 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.
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.
[-- 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 --]
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.
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
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.
> 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?
> 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
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?
> 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.
[-- 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.
[-- 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.
> 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.)
[-- 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.
>> 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.
>> 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.
> 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.
>> "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.
[-- 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 --]
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.
>> 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?
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.
> > 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.
> > 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.
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.
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.
> > 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.
>> 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.
>
> 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.
> > 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.
> 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
>> 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 ;-)
> > 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.
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. ;-))