GNU bug report logs - #1305
All code that currently beeps should use visual bell instead

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Alan Third <alan <at> idiocy.org>, 1305 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> md5i.com>, Stefan Kangas <stefan <at> marxist.se>, jasonspiro4 <at> gmail.com, Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#1305: All code that currently beeps should use visual bell instead
Date: Thu, 29 Apr 2021 19:36:01 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.