[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1305: All code that currently beeps should use visual bell instead
From: |
Stefan Monnier |
Subject: |
bug#1305: All code that currently beeps should use visual bell instead |
Date: |
Thu, 29 Apr 2021 19:36:01 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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
- bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead, (continued)
- bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead, Dmitry Gutov, 2021/04/29
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Dmitry Gutov, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Dmitry Gutov, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Dmitry Gutov, 2021/04/30
- bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead, Drew Adams, 2021/04/30
- bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead, Dmitry Gutov, 2021/04/30
- bug#1305: [External] : bug#1305: All code that currently beeps should use visual bell instead, Drew Adams, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead,
Stefan Monnier <=
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Stefan Kangas, 2021/04/29
- bug#1305: All code that currently beeps should use visual bell instead, Dmitry Gutov, 2021/04/29
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Eli Zaretskii, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Eli Zaretskii, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Gregory Heytings, 2021/04/30
- bug#1305: All code that currently beeps should use visual bell instead, Eli Zaretskii, 2021/04/30