Plans for bell character

[notcancername]

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.