starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

terminal activity indicator/alert when in background #11058

New Issue
Open
opened 2026-01-31 02:37:31 +00:00 by claunia · 23 comments
claunia commented 2026-01-31 02:37:31 +00:00
Owner
Copy Link

Originally created by @damnskippy on GitHub (Oct 17, 2020).

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.

maintainer edit: spec here

Originally created by @damnskippy on GitHub (Oct 17, 2020). 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. -------------- _maintainer edit_: [spec here](https://github.com/microsoft/terminal/issues/7955#issuecomment-1303740796)
claunia added the Issue-FeatureHelp WantedProduct-TerminalArea-UserInterface labels 2026-01-31 02:37:31 +00:00
claunia commented 2026-01-31 02:37:32 +00:00
Author
Owner
Copy Link

@damnskippy commented on GitHub (Oct 19, 2020):

@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 commented on GitHub (Oct 19, 2020): @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.
claunia commented 2026-01-31 02:37:32 +00:00
Author
Owner
Copy Link

@damnskippy commented on GitHub (Oct 19, 2020):

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).

@damnskippy commented on GitHub (Oct 19, 2020): I don't use a mac, but it seems iterm has a feature like this based on this information in this [post](https://apple.stackexchange.com/a/22354). I've seen it in one other terminal emulator as well (SecureCRT I think).
claunia commented 2026-01-31 02:37:32 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 21, 2020):

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"

@zadjii-msft commented on GitHub (Oct 21, 2020): 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"
claunia commented 2026-01-31 02:37:33 +00:00
Author
Owner
Copy Link

@damnskippy commented on GitHub (Oct 21, 2020):

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.

@damnskippy commented on GitHub (Oct 21, 2020): 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.
claunia commented 2026-01-31 02:37:33 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Oct 23, 2020):

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.

@KalleOlaviNiemitalo commented on GitHub (Oct 23, 2020): 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.
claunia commented 2026-01-31 02:37:33 +00:00
Author
Owner
Copy Link

@naikel commented on GitHub (Jan 8, 2021):

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 commented on GitHub (Jan 8, 2021): 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.
claunia commented 2026-01-31 02:37:34 +00:00
Author
Owner
Copy Link

@naikel commented on GitHub (Jan 9, 2021):

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:

naikelGintoki-2021-01-09-11-09-1

@naikel commented on GitHub (Jan 9, 2021): 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: ![naikelGintoki-2021-01-09-11-09-1](https://user-images.githubusercontent.com/7663686/104106740-65fadf00-5285-11eb-805e-5770a380c618.gif)
claunia commented 2026-01-31 02:37:34 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jan 22, 2021):

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.

@skyline75489 commented on GitHub (Jan 22, 2021): 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.
claunia commented 2026-01-31 02:37:34 +00:00
Author
Owner
Copy Link

@iuricarraro commented on GitHub (Mar 25, 2021):

MobaXterm has similar feature and very useful.
1

@iuricarraro commented on GitHub (Mar 25, 2021): MobaXterm has similar feature and very useful. ![1](https://user-images.githubusercontent.com/4460055/112541469-2f1b6c00-8d92-11eb-8611-e1e6317b6b47.png)
claunia commented 2026-01-31 02:37:35 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 2, 2022):

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:

@zadjii-msft commented on GitHub (May 2, 2022): As an example from the wild: Gnome's Console will actually [send a desktop notification when the commandline finishes](https://itsfoss.com/gnome-console/), 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
claunia commented 2026-01-31 02:37:35 +00:00
Author
Owner
Copy Link

@warpdesign commented on GitHub (Oct 7, 2022):

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.

image

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.

@warpdesign commented on GitHub (Oct 7, 2022): 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. ![image](https://user-images.githubusercontent.com/199648/194486700-11fd08a1-a11f-4059-b760-e83b09d198fd.png) 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.
claunia commented 2026-01-31 02:37:35 +00:00
Author
Owner
Copy Link

@max-programming commented on GitHub (Nov 4, 2022):

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

@max-programming commented on GitHub (Nov 4, 2022): Is this being worked on? Or is there any plugin or alternative to achieve this?
claunia commented 2026-01-31 02:37:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 4, 2022):

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 
"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:

"autoDetectRunningCommand": "automatic" PoC:
hackathon-thursday-2023

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. ↩︎

@zadjii-msft commented on GitHub (Nov 4, 2022): > 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_. <hr> 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? <hr> 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. <hr> Okay, more official spec: ```jsonc "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" <details> <summary>Proposal 1: not so good</summary> ```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 </details> #### 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 ```json "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: ![hackathon-thursday-2023](https://github.com/microsoft/terminal/assets/18356694/1574e413-9b46-4aeb-86fe-0cb708374781) 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.
claunia commented 2026-01-31 02:37:36 +00:00
Author
Owner
Copy Link

@damnskippy commented on GitHub (Nov 5, 2022):

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.

@damnskippy commented on GitHub (Nov 5, 2022): > 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.
claunia commented 2026-01-31 02:37:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 23, 2023):

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

@zadjii-msft commented on GitHub (Mar 23, 2023): 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
claunia commented 2026-01-31 02:37:36 +00:00
Author
Owner
Copy Link

@maddishah commented on GitHub (May 14, 2024):

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:

naikelGintoki-2021-01-09-11-09-1 naikelGintoki-2021-01-09-11-09-1

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

@maddishah commented on GitHub (May 14, 2024): > 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: > > ![naikelGintoki-2021-01-09-11-09-1](https://user-images.githubusercontent.com/7663686/104106740-65fadf00-5285-11eb-805e-5770a380c618.gif) [ ![naikelGintoki-2021-01-09-11-09-1](https://user-images.githubusercontent.com/7663686/104106740-65fadf00-5285-11eb-805e-5770a380c618.gif) ](https://user-images.githubusercontent.com/7663686/104106740-65fadf00-5285-11eb-805e-5770a380c618.gif) [ ](https://user-images.githubusercontent.com/7663686/104106740-65fadf00-5285-11eb-805e-5770a380c618.gif) @naikel This is the exact thing I want, can you please explain how you enabled this and which unix terminal you are using?
claunia commented 2026-01-31 02:37:37 +00:00
Author
Owner
Copy Link

@naikel commented on GitHub (May 14, 2024):

@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.

@naikel commented on GitHub (May 14, 2024): @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.
claunia commented 2026-01-31 02:37:37 +00:00
Author
Owner
Copy Link

@codebymikey commented on GitHub (Jul 11, 2024):

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:
image

@codebymikey commented on GitHub (Jul 11, 2024): This functionality is very useful for long running tasks, and works extremely well with Git Bash's MINGW64 terminal, such that ```bash 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: ![image](https://github.com/microsoft/terminal/assets/9484406/0bce7b95-2316-4446-8338-c49c3404cf69)
claunia commented 2026-01-31 02:37:37 +00:00
Author
Owner
Copy Link

@fdcastel commented on GitHub (Oct 25, 2024):

Just passing to say that I've been working with computers for over 30 years.

And, throughout that time, I've often dreamed of having something like this.

Especially... right now, as I wait for a long build task to finish.

I'm eager to see this one become a reality!

@fdcastel commented on GitHub (Oct 25, 2024): Just passing to say that I've been working with computers for over 30 years. And, throughout that time, I've often dreamed of having something like this. _Especially... right now, as I wait for a long build task to finish._ I'm eager to see this one become a reality!
claunia commented 2026-01-31 02:37:37 +00:00
Author
Owner
Copy Link

@xgdgsc commented on GitHub (Dec 2, 2024):

I also need feature like https://unix.stackexchange.com/questions/617889/is-there-a-terminal-emulator-which-can-notify-when-there-is-an-output-with-certa .

@xgdgsc commented on GitHub (Dec 2, 2024): I also need feature like https://unix.stackexchange.com/questions/617889/is-there-a-terminal-emulator-which-can-notify-when-there-is-an-output-with-certa .
claunia commented 2026-01-31 02:37:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 2, 2024):

Best way to show your support for this issue is by 👍'ing it - that's generally how we track priority around these parts.

(I also want you to do that because I want this feature too so I want all the excuses possible to work on it 😆)

@zadjii-msft commented on GitHub (Dec 2, 2024): Best way to show your support for this issue is by 👍'ing it - that's generally how we track priority around these parts. (I also want you to do that because **I** want this feature too so I want all the excuses possible to work on it 😆)
claunia commented 2026-01-31 02:37:38 +00:00
Author
Owner
Copy Link

@etxaleku commented on GitHub (Sep 18, 2025):

I would like this feature as well please. 👍

@etxaleku commented on GitHub (Sep 18, 2025): I would like this feature as well please. 👍
claunia commented 2026-01-31 02:37:38 +00:00
Author
Owner
Copy Link

@kimsey0 commented on GitHub (Jan 21, 2026):

If this flashing/color-change state can be triggered programmatically (e.g., via a terminal bell or a dedicated escape sequence), it would also be useful for AI coding agents that need to request user attention.

@kimsey0 commented on GitHub (Jan 21, 2026): If this flashing/color-change state can be triggered programmatically (e.g., via a terminal bell or a dedicated escape sequence), it would also be useful for AI coding agents that need to request user attention.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Help Wanted Issue-Feature Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11058
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?