GNU bug report logs - #77715
[PATCH] Add ring-bell functions for mode line and header line.

Previous Next

Full log

View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 77715 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#77715: [PATCH] Add ring-bell functions for mode line and header line.
Date: Fri, 11 Apr 2025 08:00:43 -0400

[Message part 1 (text/plain, inline)]

On Thu, Apr 10, 2025 at 11:01 PM Elijah Gabe Pérez <eg642616 <at> gmail.com>
wrote:

> Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> > I wrote:
> >
> >> When Emacs dings it's typically due to a user error.
> >>
> >> Where do you see the error message? In the echo area.
> >>
> >> Putting the attention-grabbing "flash" or whatever
> >> in the echo area draws your attention to it, where
> >> you see the msg telling you what happened.
> >>
> >> Why draw or keep the user's attention _away_ from
> >> that message? The user error might have little or
> >> nothing to do with the text at the cursor of the
> >> selected window.
> >>
> >> Draw the user's attention _from_ there to the helpful
> >> message.
> >
> > `visible-bell' has been around forever. Flashing
> > the entire frame (or as the Emacs manual says, "the
> > whole screen") is overkill, and it doesn't direct
> > your attention to the error message. Similar problem
> > with the alternatives I think you're considering,
> > even if they're less overkill than `visible-bell'
> > behavior.
> >
> > A modest attention-grabber, out of the way in the
> > echo area is better, IMO.
>
> I think these features could coexist together, it wouldn't hurt.
>
> Flash the mode (or header) line for bell it is something that people
> have wanted to have, see packages such as mode-line-bell, doom-themes
> (both in MELPA), and nano-bell.
>
> I made my own implementation of echo-bell:


I think the term duration is better than length when describing time
intervals.

I still prefer the unwind-protected sit-for method that guarantees the
remaps are removed to the one with the timer where I've experienced errors
intervening with a race condition creating new cookies that are not
removed.  Try mashing C-g with your timer implementation and you'll see it.

I also prefer the implementation that I proposed that takes a list of faces
to flash rather than hard-code an assumption about what users want to
flash.  Then this isn't tied to the mode line if that's not what people
want.  Is a new face really necessary just to implement a flash?  The
implementation I proposed allows the user to specify any face attributes to
define what they want for a flash.  I wouldn't use this feature without it
being more reliable and flexible.

[Message part 2 (text/html, inline)]

Previous Next

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