terminal activity indicator/alert when in background

[damnskippy]

Problem: Often times there's a command invoked on the shell prompt that's long running and takes a while, and the user switches to a different window and puts the terminal window in the background while waiting for this command/job to complete. When the job completes, user is unaware this happened until the terminal window is switched back to (foreground) or user periodically peeks to see if the job has completed.

Suggestion: If there can be some some sort of visual indicator or alert when there is terminal activity to suggest there is new output logged into the terminal, it would provide a cue to the user that the job may be complete. If the long running job happens to continually output to the terminal this wouldn't be as useful, but most times there's a job that runs for an unpredictable amount of time and then terminal returns to the prompt.

The indicator could be a temporary flashing of the window title in the task bar, and/or a change to a different shade/color until user has acknowledged the alert. Or may be display a badge on the title bar.

Alternatives considered that are not viable or great:

• use unix terminal bell (I couldn't get this to work reliably while ssh'ed into different servers), also this requires user have the sound/headphones on, and is a one time event that if the user can miss (when the bell is rung), or if there are multiple windows there is no indication as to which window/pane is the one beeping.
• use some type of window pop up (would require X or some such windowing to accomplish this, and not native to terminal).
• notification systems similar to growl/notifier/etc (in MacOS) or even the Windows notification are not accessible while ssh'ed into a remote server where such long running command is run.

Terminal output based activity detection and alert seems native and logical place to do this without relying on any other system features.

[damnskippy]

@j4james @zadjii-msft,
Here I suggested a terminal output/activity based alert mechanism. This detection will be so native to the terminal, the user doesn't have to explicitly say "notify me when done" or in cases when the user may not have had a chance to say "notify me" (user didn't anticipate/predict the command to take long to finish), and yet wants to see a notification. Using terminal output activity as the trigger will mean it will work on both local and remote (ssh) sessions.

7718 while similar seems to be a slightly different use case where the user explicitly has to request to be notified via the OSC. I think both use cases have their place. The output based notification falls flat when there the long running command is continually spewing output.

Thanks.

[damnskippy]

I don't use a mac, but it seems iterm has a feature like this based on this information in this post. I've seen it in one other terminal emulator as well (SecureCRT I think).

[zadjii-msft]

So, if this was to be implemented, and someone were to run something like a build that was displaying output constantly, wouldn't the indicator just be perpetually on? I don't really see the value in that, so there would have to be some sort of contextual way to enable/disable this.

Though I guess reading that post, the indeterminate progress wheel as the indicator kinda makes sense - then the wheel stopping spinning would be the indicator that the process stopped running. My only great disappointment is there's not a good way for the terminal to display that indicator in the taskbar icon. We could easily add the indicator to the tab itself, but that would only be visible if the window was visible. (see also #3991)

I personally think that this is better served by a combo of #3004 and having the client application emit the corresponding sequence.

Maybe we could combine the activity spinner with the indeterminate taskbar state. Add a setting to allow the user to show indeterminate state in the taskbar while the indicator is active. We'd probably want that to be overridden by whatever the client sets from the VT sequences as described in #3004, but that's not out of the realm of possibility. Obviously we'll want a setting both for enabling/disabling the indicator at all, and then a second one(?) for mirroring the indicator to the taskbar. That would only work if the "in progress" pane is the active pane, but that's good enough for most use cases I'd bet.

The longer I think about this, the more I've gone from "this seems ridiculous" to "we need to have this"

[damnskippy]

Impressive how you are able to keep these "related" issues in the head and can call out at will and tie them together :-) It's a very useful feature IMHO (shamelessly plugging my request again).

In terms of usage, one could slice the end user requirement/experience in a couple of ways:

• a long running command that continually spews output (such as a build), versus, commands that run for a while without outputting anything but when they end, terminal returns to the prompt. And in both cases having the terminal activity indicated to the user in some form is useful depending on the use case, the latter being more useful scenario.
• user knows ahead of time and explicitly requests an alert, to be notified, at the end of the long running command, versus running a command that the user is oblivious to how long the command will take to complete, or didn't expect for it to take long when launching the command unsuspectingly but wants to be notified of the status in the background.

It seems the UI options you've suggested above covers both (or all 4) cases - please correct me if I'm wrong.

Thanks as always.

[KalleOlaviNiemitalo]

Both tmux and GNU Screen have a "silence" feature that notifies the user when there has been no new output for some time. In GNU Screen, the default is 30 seconds if enabled.

[naikel]

Most of the terminal emulator apps issue some kind of indicator when the buffer changes and it's not in the active view. For example you can be running a long task in one tab and have another active tab and there should be an indication that there was a buffer change in any other tab. Like the tab title change from black to red foreground (red font). That's extremely important.

[naikel]

I know probably this is not what you guys wanted but here's my version of something similar if a non-focused tab has new output:

[skyline75489]

I think this is a reasonable feature request. AFAIK, iTerm2 has this and I think it's useful. The taskbar indicator (OSC 9;4) is useful, but not suitable for multiple tabs.

someone were to run something like a build that was displaying output constantly, wouldn't the indicator just be perpetually on?

Well yeah. But this does not bother me.

[iuricarraro]

MobaXterm has similar feature and very useful.

[zadjii-msft]

As an example from the wild: Gnome's Console will actually send a desktop notification when the commandline finishes, if it's in the background. I don't think we could possibly get the actual commandline without much deeper shell integration (or heuristics based on typing enter, which I don't love).

See also:

• 7718

• https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/13

[warpdesign]

How about something like this? A little dot appears next to the tab's title once new output was received and the tab is in the background.

I also like @naikel's suggestion: I guess this could be configurable.

Having no way to tell something has changed is a real problem: I have to switch tabs myself from time to time to see if something happened: I shouldn't have to do that.

[max-programming]

Is this being worked on? Or is there any plugin or alternative to achieve this?

[zadjii-msft]

Is this being worked on?

Nope, not yet. We haven't really settled on a design for this feature yet. Do you have a particular design in mind?

Rereading this thread, I think I like the design in https://github.com/microsoft/terminal/issues/7955#issuecomment-1271186689 the most myself. Kinda like the tab bell notification we have currently when an inactive tab BELs, but, just for any output.

---

Maybe something like: https://learn.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#bell-notification-style

notifyOnInactiveOutput:

• taskbar: if the window is inactive and any tab receives new output, flash the taskbar
• audible: if an inactive tab has new output, emit an audible bell (This will use the sounds from bellSounds, if specified)
• tab: if an inactive tab has new output, just display an icon in the tab (ala https://github.com/microsoft/terminal/issues/7955#issuecomment-1271186689 )
• ~window~: this one doesn't make sense for an inactive window
• notification: send a desktop notification if an inactive tab recieves output?

and these can be combined with each other, like the bell settings.

of course, notifyOnInactiveOutput is a gross setting name, but it's a start. Thoughts?

---

In another thread, I believe there was discussion of notifyOnNextPrompt, driven by shell integration. I think both are probably valuable, though "next output" is strictly a superset of "next prompt". That was in #6372.[^1].

I suppose window kinda does work for notifyOnNextPrompt though. Hmm.

---

Okay, more official spec:

"OutputNotificationStyle": {
  "oneOf": [
    {
      "type": "boolean"
    },
    {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "taskbar",
          "audible",
          "tab",
          "notification"
        ]
      }
    },
    {
      "type": "string",
      "enum": [
        "taskbar",
        "audible",
        "tab",
        "notification"
        "all",
        "none"
      ]
    }
  ]
},

// ...

"Profile": {
  "properties": {
    // ...
    "notifyOnInactiveOutput": {
      "$ref": "#/$defs/OutputNotificationStyle",
      "default": "none",
      "description": "When this profile receives output in an inactive tab, raise a notification of the given type"
    },
    "notifyOnNextPrompt": {
      "$ref": "#/$defs/OutputNotificationStyle",
      "default": "none",
      "description": "When the commandline application returns to the prompt, raise a notification of the given type. This requires shell integration to be enabled."
    },

true -> "tab"

---

Try to combine with #1620, #8449. These are a pair of related scenarios:

• "I want the terminal to show an indicator in the tab while a command is running"
  • for an indicator, we can use an indeterminate progress ring
• "I want the Terminal to show a progress ring based on the content of the last line of the buffer"

Proposal 1: not so good

```json "onInactiveOutput": { "style": ["taskbar", "audible", "tab", "notification"], "progress": "default|automatic" } ``` Eh, wait, I don't love that. Cause: * `onInactiveOutput `is an object, but `notifyOnNextPrompt` isn't (doesn't make sense to raise progress on the next prompt) * `progress: automatic` as a subset of `onInactiveOutput` implies that it wouldn't set progress if the tab was active

proposal 2

I think we can combine these to some setting that tells the control to report "progress" even if no progress was set:

• disabled: don't do this
• automatic: if we got a FTCS_COMMAND_EXECUTED (133;C), then any output, set our progress state to indeterminate
• progress: walk+check the last line of the buffer: if it's got {(\d)%, (\d)/(\d)} in it, then use that number instead

"autoDetectRunningCommand": "disabled|automatic|progress"

NOTES:

• If we do "autoDetectRunningCommand": "automatic", progress rings take precedence over the tab icon. So notifyOn* would need to be a separate icon.
• "autoDetectRunningCommand": "automatic" should end on a prompt mark
• "autoDetectRunningCommand": "automatic" should not do the thing on ONLY inactive/hidden panes

---

hackathon 2023 notes:

• dev/migrie/fhl-fall-2023/3991-progress-before-connection -> #3991
  • dev/migrie/fhl-fall-2023/1620-automatic-tab-progress -> #1620

"autoDetectRunningCommand": "automatic" PoC:

Something's sorta wrong when a connection first starts. dir also leaves the progress state polluted, even without shell integration

[^1]: I should really pick one of these as the thread and close the other as a dupe.

[damnskippy]

notification: send a desktop notification if an inactive tab recieves output?

Is this a toast notification or some thing like that? If yes, perhaps it can show the window title and any other useful info in it, and when clicked on the notification could switch to the window (raise to foreground) that the notification is for? Thanks.

[zadjii-msft]

note to self: an example of the notification style:

https://user-images.githubusercontent.com/18356694/227358435-8c4e7533-e4a9-4740-9779-0e29c9b1d195.mp4

credit: https://mastodon.social/@raggesilver/110045050437013369

[maddishah]

I know probably this is not what you guys wanted but here's my version of something similar if a non-focused tab has new output:

@naikel This is the exact thing I want, can you please explain how you enabled this and which unix terminal you are using?

[naikel]

@maddishah at the time I modified the source code of this project for that, but I never send a pull request for it because it seemed nobody liked the design for it.

It's long gone now.

[codebymikey]

This functionality is very useful for long running tasks, and works extremely well with Git Bash's MINGW64 terminal, such that

sleep 5 && tput bel

Will bring the window back into focus once it's completed even if it was previously minimized.

This might be a bit of a different use case, but the bell behaviour is more direct in that the program requires focus or attention of some kind, and the user should react accordingly.

The behaviour is also configurable here: