Plans for bell character

[cn-cn-cn]

Sup,
Ghostty currently doesn't seem to do anything when faced with a bell character (printf \x7).

ghostty/src/termio/stream_handler.zig

Lines 326 to 327 in 90c59f2

	_ = self;
	log.info("BELL", .{});

What's planned for that?

[jcollie]

See #2231

[mitchellh]

The lack of a long term plan is part of the reason I haven't merged #2231. The other is that there are a lot of dependencies it brings in and I want to think about that a bit more. I think in general the plan for the bell character is to at the very least provide an option for (1) ignore (2) audio (3) visual (4) both. I'd love to hear any ideas people have in general. Once we have some solid idea of what we want, we can bike shed on configuration styles and implementation choices.

[kfet]

What I find useful is icon badges and a notification. As others I tend to use a bel to indicate end of commands which I care to be aware of.

[vikanezrimaya]

I would rather have Ghostty wrap libcanberra or GSound (which is effectively a GObject wrapper around libcanberra) so it can use the system sound theme instead of something bespoke like the bundled bell sound in #2231 or a separate config option.

[cwarden]

I'm just looking for a visual bell that flashes the screen like xterm or alacritty.

[ftpd]

I'm seconding the idea of icon badge on macOS.

[dolmen]

A visual only flash in the terminal area (ex: temporary inverse foreground/background color, or apply a GL shader) could probably be implemented in a portable way (independant of the OS) without bringing huge dependencies (contrary to audio).

[jcollie]

In terms of configuration, I'd like to see a style similar to shell-integration-features where there's one option that can enable/disable many features. This takes advantage of generic code in Ghostty for handling these sorts of configs and it's a little more future-proof.

So you'd have something like the following:

bell-features = audio,no-visual,no-message

For the initial PR, we can limit the features to audio bells only to minimize the areas of code being touched and make review easier.

[dolmen]

For the case of a visual representation of BEL, I think it would be helpful to have visual information of the location where the BEL occurred: the location of the cursor where the BEL has been printed. I'm thinking at flashing the whole terminal (using a GL shader?) or just the scroll region, but with a visual effect that highlight the source position of the cursor.

I'm thinking at waves like when throwing a drop of water on a calm lake, seen from the sky. Multiple BEL can happen at different locations and that could to a rain-on-a-lake effect.

If a scroll event an asynchronous animation must continue to play still attached to the location where the BEL was printed, updated according to scrolling.

[dolmen]

About visual BEL, what do you think about:

• synchronous (blocking terminal updates until animation is done)
• vs asynchronous (animation starts when BEL is recieved, but lasts for a few milliseconds after flow continues). In that case, the display of multiple BEL happening has to be handled.

[jcollie]

IMHO blocking terminal updates would be a really bad idea. From what I know of the graphics rendering timeline it wouldn't be difficult to have a timestamp object that says "show the visual bell animation until the current time reaches this timestamp". When we receive a BEL character that timestamp gets set to now + 500ms (or whatever interval you like). That way the animation is shown for at most 500ms from the time the last BEL character was received.

[jpaugh]

Blocking terminal updates from a non-interactive script because of a UI update is really heavy-handed. I'd rather miss the second bel than have that.

Ignoring all bels during the animation would not be that bad, especially if the animation is short enough not to be annoying (Something like .2 seconds).

If you want to indicate every bel that comes in, just restart the animation. That will provide a visual "jolt" to the user, and it is reasonably intuitive to me (as a user).

Extending the animation would be ambiguous, and ultimately conveys the same meaning as ignoring the second bell. Even if the user understands why the animation lasts longer than usual, would a user be able to distinguish between 2 bels and 3?

[jneuhaus]

I'm in favor of an audible tone for BEL, although it does seem that other terminal applications do not send an audible (e.g. Terminator.) My use-case is monitoring a process while ssh into a system...I have a bash script which runs a process, checks the result, then sleeps (all in a loop.) If the process completes, I send a BEL (in another loop) which alerts me that the process is complete. I'm not in front of the system doing this, but nearby, which is why the audible is useful.

[pluiedev]

My 2¢ on this issue is that we should mostly rely on what the system defines to be an appropriate response to a generic system bell. On Linux, GTK has a dedicated method for it and on macOS we have the lovely-named NSBeep. A maximalist approach à la Kitty would cause very high maintenance burden for something that is IMO just an audiovisual flourish.

Of course, that isn't to say that we couldn't strike a balance between only offering only a system bell and the whole charcuterie plate of options Kitty provides, though each kind of bell needs to be considered individually:

• Audio: While relatively easy to implement on macOS, on Linux it's somewhat of a nightmare. libcanberra is considered obsolete and directly using GSound requires bundling our own sound theme in a way, like in gtk: implement custom audio bell #5326. This breaks the "everything looks and feels (and sounds) native" paradigm since we pretty much have to fall back to the default FreeDesktop sound theme, while on say KDE Plasma the rest of the system uses the Ocean sound theme, designed specifically for Plasma.

  Additionally, some systems (namely Plasma again) allows one to customize what sound should be played when a system bell is triggered. I think that's a much healthier approach to this issue as users can instruct their system as to which sound to play, and ideally the whole system would use that sound (kind of like macOS).

• Visual flashes: I think we can all agree that rapid flashes à la Konsole or Alacritty looks bad and hurts one's eyes (potentially life-threatening for people who suffer from photosensitive epilepsy). An alternative would be animated, smoother fading like what Kitty does, but that would require a rewrite of our graphics pipeline to support smooth animations without incurring large performance costs — a goal perhaps for 1.2, but it would take considerable effort to implement.

• System notifications/icon badges: Basically free.

• Focus requests/attention requests/jumping-up-and-down-on-the-dock: Also basically free. (I would consider making this enabled by default since it's a relatively unobtrusive way of grabbing the user's attention. It's also fairly standard on both Linux and macOS desktops.)

• Calling custom scripts: I am really against this. Running a script potentially hundreds of times a second when a program dumps out ^G like a flood sounds like a recipe for disaster. Ghostty is a terminal emulator, not a script runner.

[jcollie]

Is that using "adw_tab_page_set_needs_attention"? That would be quite easy to implement for us. I think for a split at minimum you'd want that split to become the focused split on that tab if a BEL is received. Could maybe add a CSS border around the split that fades after a few seconds?

[jcollie]

FYI, I updated the #5326 so that we don't need to include an audio theme in Ghostty. It implements two options system and audio - system uses the aforementioned gdk_system_beep to play the system beep, and audio now only plays a user-supplied audio file. Both of these options should be easily implementable on macOS.

[tristan957]

Is that using "adw_tab_page_set_needs_attention"?

Yes it is!

[dbast]

maybe beyond the scope of this discussion, but there are more "signals" to potentially react to than only special characters (like the bell) being detected ... like a user runs a specific command, e.g. git push triggering a specific action of the terminal ... for things like https://github.com/bomanimc/gitrocket :)

[00-kat]

That is probably out of the scope of this discussion, but do keep in mind that it may be possible to configure some tools to print out a bell character; for example, I had a in bell character in my sudo prompt so that I get notified whenever something tries to run sudo.

[jcollie]

#7087 fixes this for GTK. macOS support is a TODO.

[jcollie]

#7099 for tracking BELL support on macOS.