Use terminal bell for cross-platform breathing segment signals

[marekkowalczyk]

Summary

Implement use of the terminal "bell" (\a) to signal the end of each breathing segment. This will help ensure compatibility across Linux (including WSL 2), macOS, and other operating systems without relying on system-specific audio tools.

Motivation

• Ensures all users, especially those on Linux or using minimal setups, get a consistent timing notification.
• Reduces the need for external sound dependencies or configuration.
• Keeps the CLI utility simple and portable.

Details

• Upon completion of each breathing segment, the CLI should output the terminal bell character (\a / ASCII 7), which most terminals render as an alert sound or notification.
• This feature should be enabled by default, or easily selectable with a command-line argument/flag if a more customizable solution is desired.

Acceptance Criteria

• CLI emits terminal bell at the end of each breathing segment when this feature is enabled.
• Works seamlessly on Linux, macOS, and Windows (WSL2/WSLg/etc.).
• Document the feature and provide instructions for users who may have terminal bell disabled.

---

This issue is a sub-issue of #4.

[Epholys]

Isn't the terminal bell already implemented?

I see it in the code, and on my Linux setup (WSL2 under Windows 11), it already works:

breathe-cli/breathe.py

Lines 219 to 221 in ac740cb

	elif audio_mode == 'bell':
	sys.stdout.write('\a')
	sys.stdout.flush()

[marekkowalczyk]

i think you're right. i wrote on impulse from a discussion that suggested it's not there. either close or change to "test on different terminals / systems". wdyt?

[Epholys]

From what I know, the terminal bell is widely supported amongst mainstream terminals. The issues are that it can be interpreted differently (sound, notification, flashing, ...), that the user can choose to remove it, that some multiplexer can filter them, or that accessing remote servers through ssh or other means doesn't transmit it.

But it's debatable if it's really necessary to implement workarounds, having a bell as "last resort" is an already implemented good idea. Much better than nothing, and I don't think another simple and easy solution can fill this role.

For this issue, maybe testing quickly for the main terminals (and maybe systems) to see if everything is in order could be a good idea, yes.

Another thing could be to inform the user about this fallback, but I don't how it can be implemented without cluttering the minimalist (rightly!) user interface.

---

But, in the end, the task #7 is the main issue, this one is just the last fallback, IMO.

So, I'd let you decide what's best, I think I put all my thoughts in a too long comment haha