Add settings for "notifying" on "activity"

[carlos-zamora]

This PR implements the proposal in this comment. It adds 3 settings:

• notifyOnInactiveOutput: send a "notification"(below) of some kind when an inactive tab has new output.
• notifyOnNextPrompt: Similarly, but when we get a new prompt start (requires shell integration)
• autoDetectRunningCommand: attempt to automatically detect the progress state of this profile

For the notifyOn* settings, they take any combination of the following flags:

• tab: flash the taskbar
• audible: emit an audible bell (This will use the sounds from bellSounds, if specified)
• taskbar: display an icon in the tab (ala terminal activity indicator/alert when in background #7955 (comment) ) (basically, similar to the bell icon)
• notification: send a desktop "toast" (read: notification). Clicking that notification will focus the tab that sent it

For the autoDetectRunningCommand setting, we support:

• disabled: don't do this
• automatic: (requires shell integration) if we got a FTCS_COMMAND_EXECUTED  (133;C), then any output, set our progress state to indeterminate

Validated using this config:

"defaults":
{
	"autoDetectRunningCommand": "automatic",
	"autoMarkPrompts": true, // Needed even when your OMP config has shell integration enabled
	"rightClickContextMenu": true,
	"showMarksOnScrollbar": true
},
"list":
[
	{
		"commandline": "pwsh -nologo",
		"name": "Inactive Output",
		"notifyOnInactiveOutput":
		[
			"taskbar",
			"audible",
			"tab",
			"notification"
		]
	},
	{
		"commandline": "pwsh -nologo",
		"name": "Next Prompt",
		"notifyOnNextPrompt":
		[
			"taskbar",
			"audible",
			"tab",
			"notification"
		]
	},

• Closes terminal activity indicator/alert when in background #7955 (via notifyOnInactiveOutput)
• Closes Notification after a long running command finishes #6372 (via the notifyOnNextPrompt)
• Closes Add a "tab busy indicator" to show when a tab has belled or has output #1620 (via autoDetectRunningCommand)
• Related to Send Desktop Notification via VT Sequence (OSC777) #7718

Heavily based on #19935
Co-authored by @zadjii-msft

[carlos-zamora]

Tested this out, it's pretty cool.
Reviewed it myself and using GHCP, everything looks good.

The only thing I can think of is the possibility of adding the experimental. prefix to these settings, but even then, I don't think that necessarily does anything. Like, when would it exit experimental?

So yeah, marked this as ready for review. Enjoy y'all! 😊

[heaths]

What about a setting for duration? Ghostty has this as well. I may only want to see this after, say, 10s and not a command that maybe takes a second and I quickly flip away intending to come back in a few seconds. A longer job is more likely something we'll "walk away from" for a longer period instead of just flipping windows back and forth a bit.

If someone really wanted to be alerted for every command when the window is inactive, they can set this to 0 (or maybe that's the default).

[carlos-zamora]

Hmm... ghostty calls these settings activity-monitor and activity-monitor-threshold. So, we could name this notifyOnInactiveOutputThreshold and also have it take an int representing seconds (default of 0). Then just place them next to each other in the settings UI.

[heaths]

Having a higher default (IIRC, Ghostty's is 30s when enabled) might solve the other issue you mentioned, but you could also debounce notifications. If they come in within Xs (maybe also configurable), don't notify. Frankly, given the goal is to notify you some task is done - and this would seem to be a long-running task, IMO, since any quick task you're probably coming back to frequently - the "threshold" having a higher default like 30s would probably be sufficient - at least as a start.

[carlos-zamora]

I was just using this feature with Copilot, and it was sending a ton of notifications as it was thinking.
At first, I was thinking that we should only let the session send one notification of this type, but now I'm not sure if that's the right approach. I'm particularly thinking of situations where the attached CLI app may send a bit of output, then wait, then send more. I guess in a situation like that, we definitely want a notification on the second one, and maybe on the first?

Thoughts? CC @DHowett @zadjii-msft

[zadjii-msft]

IMO:

I think we need to send one notification when the tab gets activity and then no more until that pane is focused.
If it emits some text, and you don't focus it, and then five minutes later it emits some more text, we don't send a second notification. That pane is already in the "there was inactive activity" state. We don't need to send another notification until the user activates it (to dismiss that state)

Like, consider how the in-tab indicator would work. It's like the bell icon. "this tab did a thing" stays until the user activates it to dismiss that state.