缺乏与现有终端铃声集成的终端状态协议

原话 · @Anonymous

The BSDs have had a version of this for many, many years. If you hit ^T on the terminal, you deliver a SIGINFO to the application you're waiting for. By default, you get the program name, what its blocked on, and info about real/user/sys time and memory use.Starting an emacs window in the fg:% emacs ^T emacs-31.1 64938 [select] 2.89r 0.75u 0.06s 6% 122404k

原话 · @Anonymous

The problem `OSC 7501` addresses would slot almost perfectly into [UAPI.15 OSC 3008](https://uapi-group.org/specifications/specs/osc_context/#met...).It's already implemented by `systemd` and is available in Ubuntu 26.04.I'd rather see `OSC 3008` being extended.

原话 · @Anonymous

I like the idea, but we already have the terminal bell. In my setup, when an agent is done or needs something, it emits a bell. Based on config, this results in a desktop notification if I’m not in the terminal, or a toast from my multiplexer if I’m in the terminal. The terminal pane gets a colored “bell” icon in its title that is cleared when I attach to it.The total lack of mention of the terminal bell in the article is weird. I think it needs to be addressed for the protocol to be taken seriously. More granular info sounds nice, but also nice is the simplicity of the bell.

原话 · @Anonymous

I've been using a poor mans version of this for decades.My iTerm2 is configured to show activity, new-output and visual bell in the tab. On Linux I have an approximation for WezTerm.I have a bell command that I can use in a pipeline or sequence to produce the bell on events I'm interested in. Trivial case is when a program finishes.I have a fancy alias that can be used in a shell command sequence and which produces different sounds depending on the exit status of the preceding command in addition to sending the terminal bell.