Add an optional status bar to the bottom #4839

@egmontkob commented on GitHub (Nov 6, 2019):

Username and hostname can probably be squeezed into OSC 7 without problems, using the standard file://username@hostname/path... syntax. Alas, it needs efforts from OSes (shells etc.) actually emitting it, which doesn't really seem to happen.

@egmontkob commented on GitHub (Nov 6, 2019): Username and hostname can probably be squeezed into OSC 7 without problems, using the standard file://username@hostname/path... syntax. Alas, it needs efforts from OSes (shells etc.) actually emitting it, which doesn't really seem to happen.

claunia commented

@mdtauk commented on GitHub (Nov 6, 2019):

I'd like to throw my voice in for enabling the status bar to be in the window shell itself, but also to be placed within the terminal area itself, using the profile's colour scheme.

@mdtauk commented on GitHub (Nov 6, 2019): I'd like to throw my voice in for enabling the status bar to be in the window shell itself, but also to be placed within the terminal area itself, using the profile's colour scheme. ![59804721-0fb2fd80-92e7-11e9-9cd6-7d7a242feda5](https://user-images.githubusercontent.com/7389110/68338131-c1f23280-00d9-11ea-8f75-cabb704bbc60.png) ![57567807-a500cf00-73d6-11e9-806f-39cc316e916b](https://user-images.githubusercontent.com/7389110/68338251-f665ee80-00d9-11ea-9a25-5b84a5f9f442.png) ![59804746-2194a080-92e7-11e9-8ee7-cde122dceb64](https://user-images.githubusercontent.com/7389110/68338140-c585b980-00d9-11ea-92dd-fcab2d100703.png) ![57567803-9fa38480-73d6-11e9-827a-549de5d65a62](https://user-images.githubusercontent.com/7389110/68338261-fd8cfc80-00d9-11ea-938c-1fce4a2881fa.png)

claunia commented

@DHowett-MSFT commented on GitHub (Nov 6, 2019):

It's just that, like, everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

@DHowett-MSFT commented on GitHub (Nov 6, 2019): It's just that, like, everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

claunia commented

@mdtauk commented on GitHub (Nov 6, 2019):

It's just that, like, everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

Progress could be displayed?

Linux profiles may offer more information to display.

Azure cloud may have local timezone.

@mdtauk commented on GitHub (Nov 6, 2019): > It's just that, like, everything that we can conceivably put in the status bar is already on the screen somewhere, innit? Progress could be displayed? Linux profiles may offer more information to display. Azure cloud may have local timezone.

claunia commented

@egmontkob commented on GitHub (Nov 6, 2019):

Progress [...] Linux profiles [...] Azure local timezone

All of these require heavy design and cooperation between components (like Linux, Azure etc.), not just some easy UI work.

@egmontkob commented on GitHub (Nov 6, 2019): > Progress [...] Linux profiles [...] Azure local timezone All of these require heavy design and cooperation between components (like Linux, Azure etc.), not just some easy UI work.

claunia commented

@egmontkob commented on GitHub (Nov 6, 2019):

everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

There's a clock in the bottom right corner of your desktop. There would be a clock in the bottom right corner of your terminal. If you launch tmux inside, you have a clock in the bottom right corner of the terminal area (in tmux's status bar). Luckily my favorite text editor can also display the time :)

@egmontkob commented on GitHub (Nov 6, 2019): > everything that we can conceivably put in the status bar is already on the screen somewhere, innit? There's a clock in the bottom right corner of your desktop. There would be a clock in the bottom right corner of your terminal. If you launch tmux inside, you have a clock in the bottom right corner of the terminal area (in tmux's status bar). Luckily my favorite text editor can also display the time :)

claunia commented

@mdtauk commented on GitHub (Nov 6, 2019):

everything that we can conceivably put in the status bar is already on the screen somewhere, innit?

There's a clock in the bottom right corner of your desktop. There would be a clock in the bottom right corner of your terminal. If you launch tmux inside, you have a clock in the bottom right corner of the terminal area (in tmux's status bar). Luckily my favorite text editor can also display the time :)

This would also highlight the plus side for displaying the status bar within the terminal area with profile colouring - so when the terminal is full screen or maximised, it will appear and not be distracting

@mdtauk commented on GitHub (Nov 6, 2019): > > everything that we can conceivably put in the status bar is already on the screen somewhere, innit? > > There's a clock in the bottom right corner of your desktop. There would be a clock in the bottom right corner of your terminal. If you launch tmux inside, you have a clock in the bottom right corner of the terminal area (in tmux's status bar). Luckily my favorite text editor can also display the time :) This would also highlight the plus side for displaying the status bar within the terminal area with profile colouring - so when the terminal is full screen or maximised, it will appear and not be distracting

claunia commented

@driver1998 commented on GitHub (Nov 7, 2019):

What about indicators for caps lock, numlock, insert and so on? These can be useful for people who have no indicators on their keyboards. Also it is a classic thing to have on status bar :)

@driver1998 commented on GitHub (Nov 7, 2019): What about indicators for caps lock, numlock, insert and so on? These can be useful for people who have no indicators on their keyboards. Also it is a classic thing to have on status bar :)

claunia commented

@egmontkob commented on GitHub (Nov 7, 2019):

In my serious opinion, everything that is not related to the terminal per se (e.g. date+time, caps+num lock...) should go to the desktop (taskbar) and not to the terminal.

@egmontkob commented on GitHub (Nov 7, 2019): In my serious opinion, everything that is not related to the terminal per se (e.g. date+time, caps+num lock...) should go to the desktop (taskbar) and not to the terminal.

claunia commented

2026-01-30 23:57:53 +00:00

@driver1998 commented on GitHub (Nov 7, 2019):

It might be right for caps lock/numlock, but insert/override status is managed per-app, not system wide.
Also ConHost changes cursor shape when Insert status changes.

Edit: well it seems Powershell doesn't actually support override mode, only insert mode... But CMD supports both.

@driver1998 commented on GitHub (Nov 7, 2019): It might be right for caps lock/numlock, but insert/override status is managed per-app, not system wide. Also ConHost changes cursor shape when Insert status changes. Edit: well it seems Powershell doesn't actually support override mode, only insert mode... But CMD supports both.

claunia commented

@mdtauk commented on GitHub (Nov 7, 2019):

In my serious opinion, everything that is not related to the terminal per se (e.g. date+time, caps+num lock...) should go to the desktop (taskbar) and not to the terminal.

Some people like to use the terminal in full screen, without other UI.

Also if connecting to a server or data-centre, there could be a local time zone to consider.

There are examples of terminals with status bars (probably a third party app running) so it is something that could be offered as an extension in the future, if the terminal team doesn't want to provide one inbox - but creating the ability for a status bar to display, either in the shell or in the terminal space, is worth adding.

Rather than adding all the functionality people want into a Status Bar - what if it becomes a surface within the terminal, that developers and plug-in/extension makers could put content into. This handles the issue of backwards compatibility, as it will be something loaded in by the Windows Terminal itself.

@mdtauk commented on GitHub (Nov 7, 2019): > In my serious opinion, everything that is not related to the terminal per se (e.g. date+time, caps+num lock...) should go to the desktop (taskbar) and not to the terminal. Some people like to use the terminal in full screen, without other UI. Also if connecting to a server or data-centre, there could be a local time zone to consider. There are examples of terminals with status bars (probably a third party app running) so it is something that could be offered as an extension in the future, if the terminal team doesn't want to provide one inbox - but creating the ability for a status bar to display, either in the shell or in the terminal space, is worth adding. ![image](https://user-images.githubusercontent.com/7389110/68374055-01516b00-013c-11ea-8895-fc37759e10bb.png) ![image](https://user-images.githubusercontent.com/7389110/68374515-f0552980-013c-11ea-99ad-341fe49140ae.png) ---- Rather than adding all the functionality people want into a Status Bar - what if it becomes a surface within the terminal, that developers and plug-in/extension makers could put content into. This handles the issue of backwards compatibility, as it will be something loaded in by the Windows Terminal itself.

claunia commented

2026-01-30 23:57:53 +00:00

@egmontkob commented on GitHub (Nov 7, 2019):

Some people like to use the terminal in full screen, without other UI.

I know. The question is: what does "without other UI" mean exactly? If they want to hide the taskbar, wouldn't they also want to hide the terminal's status bar? :-)

Also if connecting to a server or data-centre, there could be a local time zone to consider.

As said earlier, this requires backend work. In fact, a freaking huge amount of backend work, something along the lines of transferring the entire timezone database, or at least info about any forthcoming DST change, or transferring the local time every minute or so (even if an app is running and is the middle of emitting an escape sequence, without breaking it in hafl), or risking the clock slowly drifting away, or temporarily going off during a DST change or a sudden adjustment (the latter shouldn't happen in professional environment), or getting it stuck with a slight offset if the network was laggy when the timestamp was sent over... It's fairly easy to get it mostly working, it's extremely hard to get it robustly working. But if done, certainly this clock would be a reasonable thing to have, since then it's a per-terminal thing and not the same as the clock shown on the taskbar.

@egmontkob commented on GitHub (Nov 7, 2019): > Some people like to use the terminal in full screen, without other UI. I know. The question is: what does "without other UI" mean exactly? If they want to hide the taskbar, wouldn't they also want to hide the terminal's status bar? :-) > Also if connecting to a server or data-centre, there could be a local time zone to consider. As said earlier, this requires backend work. In fact, a freaking huge amount of backend work, something along the lines of transferring the entire timezone database, or at least info about any forthcoming DST change, or transferring the local time every minute or so (even if an app is running and is the middle of emitting an escape sequence, without breaking it in hafl), or risking the clock slowly drifting away, or temporarily going off during a DST change or a sudden adjustment (the latter _shouldn't_ happen in professional environment), or getting it stuck with a slight offset if the network was laggy when the timestamp was sent over... It's fairly easy to get it mostly working, it's extremely hard to get it robustly working. But if done, certainly this clock would be a reasonable thing to have, since then it's a per-terminal thing and not the same as the clock shown on the taskbar.

claunia commented

2026-01-30 23:57:53 +00:00

@j4james commented on GitHub (Nov 7, 2019):

Something worth mentioning, is that a status line is one of the features of the VT320 terminal (and assumedly later models as well). And this was something that terminal applications could choose to overwrite with custom content, or even turn off completely if they wanted to use that space for their main content.

So if you decide to render this as part of the main viewport area, it might be worth considering where it could be made somewhat compatible with the VT status line, and at least having an option for applications to control it with the various status line escape sequences (not necessarily from day 1, but something to consider in the design).

@j4james commented on GitHub (Nov 7, 2019): Something worth mentioning, is that a [status line](https://www.vt100.net/docs/vt320-uu/chapter4.html#S4.6 ) is one of the features of the VT320 terminal (and assumedly later models as well). And this was something that terminal applications could choose to overwrite with custom content, or even turn off completely if they wanted to use that space for their main content. So if you decide to render this as part of the main viewport area, it might be worth considering where it could be made somewhat compatible with the VT status line, and at least having an option for applications to control it with the various status line escape sequences (not necessarily from day 1, but something to consider in the design).

claunia commented

2026-01-30 23:57:54 +00:00

@mdtauk commented on GitHub (Nov 7, 2019):

You could display the amount of time it took to complete the last command maybe, as a Status Bar option.

@mdtauk commented on GitHub (Nov 7, 2019): You could display the amount of time it took to complete the last command maybe, as a Status Bar option.

claunia commented

2026-01-30 23:57:54 +00:00

@egmontkob commented on GitHub (Nov 7, 2019):

@mdtauk All these things you suggest to display there are pieces of information that are not known by the terminal.

@egmontkob commented on GitHub (Nov 7, 2019): @mdtauk All these things you suggest to display there are pieces of information that are _not_ known by the terminal.

claunia commented

2026-01-30 23:57:54 +00:00

@mdtauk commented on GitHub (Nov 7, 2019):

@mdtauk All these things you suggest to display there are pieces of information that are not known by the terminal.

I guess not. There may be use cases that could benefit, and other popular terminals do support displaying a status bar.

@mdtauk commented on GitHub (Nov 7, 2019): > @mdtauk All these things you suggest to display there are pieces of information that are _not_ known by the terminal. I guess not. There may be use cases that could benefit, and other popular terminals do support displaying a status bar.

claunia commented

@egmontkob commented on GitHub (Nov 7, 2019):

other popular terminals do support displaying a status bar.

Can you give examples please? (I mean, of a status bar displaying a progress bar (progress of what?), local time, the time it took to run a command etc.)

@egmontkob commented on GitHub (Nov 7, 2019): > other popular terminals do support displaying a status bar. Can you give examples please? (I mean, of a status bar displaying a progress bar (progress of what?), local time, the time it took to run a command etc.)

claunia commented

https://conemu.github.io/en/Progress.html#progress-on-windows7-taskbar

@mdtauk commented on GitHub (Nov 7, 2019):

other popular terminals do support displaying a status bar.

Can you give examples please? (I mean, of a status bar displaying a progress bar (progress of what?), local time, the time it took to run a command etc.)

There is a plan to add a progress ring to the TabView control's tabs, and it was mentioned in another issue that there is a way to detect progress and the team want to use the tab progress ring to display progress.

To throw 2¢ in from the Terminal team:

This is definitely a feature I'd look for as well. One thing we want to support in the future is the ConEmu "progress" VT sequences, which can be used for setting the "taskbar progress status" for the terminal. Since we could have multiple tabs, each with their own progress status, I'd love if there was a way to display this status within each tab as well, not just in the taskbar :)

See also microsoft/terminal#3004

https://github.com/microsoft/microsoft-ui-xaml/issues/1386

@mdtauk commented on GitHub (Nov 7, 2019): > > other popular terminals do support displaying a status bar. > > Can you give examples please? (I mean, of a status bar displaying a progress bar (progress of what?), local time, the time it took to run a command etc.) There is a plan to add a progress ring to the TabView control's tabs, and it was mentioned in another issue that there is a way to detect progress and the team want to use the tab progress ring to display progress. https://conemu.github.io/en/Progress.html#progress-on-windows7-taskbar ---- >To throw 2¢ in from the Terminal team: > >This is definitely a feature I'd look for as well. One thing we want to support in the future is the ConEmu "progress" VT sequences, which can be used for setting the "taskbar progress status" for the terminal. Since we could have multiple tabs, each with their own progress status, I'd love if there was a way to display this status within each tab as well, not just in the taskbar :) > >See also microsoft/terminal#3004 > https://github.com/microsoft/microsoft-ui-xaml/issues/1386

claunia commented

@egmontkob commented on GitHub (Nov 7, 2019):

I said this information is not known by the terminal.

You link to a page mentioning a "simple AI" (LOL) examining the output of several applications and making a guess. Sure, that is a way that can get you a progress bar in certain specific cases.

Terminals don't understand a single bit of semantics about what is happening inside. They just receive instructions and paint their canvas accordingly. Making conclusions, guesses about this, using a "simple AI" or whatever, is certainly a direction developers could begin exploring, but is probably going to take way too much time and way too much ongoing maintenance cost, for way little advantage. I'm not a fan of this direction.

Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Still a lot of work, but at least more reliable, with less ongoing maintenance cost, and potentially can be supported by other terminals too.

Similar story for other ideas you had in mind, e.g. sure a terminal could try to understand when a command was started and when it completed, but it'd be extremely fragile. Or it could be properly designed and then explicitly implemented in relevant apps. Both approaches are extremely costly in terms of developer efforts.

@egmontkob commented on GitHub (Nov 7, 2019): I said this information is not _known_ by the terminal. You link to a page mentioning a "simple AI" (LOL) examining the output of several applications and making a _guess_. Sure, that is a way that can get you a progress bar in certain specific cases. Terminals don't _understand_ a single bit of semantics about what is happening inside. They just receive instructions and paint their canvas accordingly. Making conclusions, guesses about this, using a "simple AI" or whatever, is certainly a direction developers could begin exploring, but is probably going to take way too much time and way too much ongoing maintenance cost, for way little advantage. I'm not a fan of this direction. Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Still a lot of work, but at least more reliable, with less ongoing maintenance cost, and potentially can be supported by other terminals too. Similar story for other ideas you had in mind, e.g. sure a terminal could try to understand when a command was started and when it completed, but it'd be extremely fragile. Or it could be properly designed and then explicitly implemented in relevant apps. Both approaches are extremely costly in terms of developer efforts.

claunia commented

@mdtauk commented on GitHub (Nov 7, 2019):

I said this information is not known by the terminal.

You link to a page mentioning a "simple AI" (LOL) examining the output of several applications and making a guess. Sure, that is a way that can get you a progress bar in certain specific cases.

Terminals don't understand a single bit of semantics about what is happening inside. They just receive instructions and paint their canvas accordingly. Making conclusions, guesses about this, using a "simple AI" or whatever, is certainly a direction developers could begin exploring, but is probably going to take way too much time and way too much ongoing maintenance cost, for way little advantage. I'm not a fan of this direction.

Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Still a lot of work, but at least more reliable, with less ongoing maintenance cost, and potentially can be supported by other terminals too.

Similar story for other ideas you had in mind, e.g. sure a terminal could try to understand when a command was started and when it completed, but it'd be extremely fragile. Or it could be properly designed and then explicitly implemented in relevant apps. Both approaches are extremely costly in terms of developer efforts.

The reply to that comment is about making the progress display in the Tab itself. If it can display in there, it could also be displayed in a Status Bar.

Anyway, the original concept teaser design has a Status Bar, and my point is more about where that status bar is rendered.

If there is a real lack of things to put in a status bar, then it could be opened up to extension programmers. Even a looping gradient or fun ASCII animation could be enough reason for a bar.

@mdtauk commented on GitHub (Nov 7, 2019): > I said this information is not _known_ by the terminal. > > You link to a page mentioning a "simple AI" (LOL) examining the output of several applications and making a _guess_. Sure, that is a way that can get you a progress bar in certain specific cases. > > Terminals don't _understand_ a single bit of semantics about what is happening inside. They just receive instructions and paint their canvas accordingly. Making conclusions, guesses about this, using a "simple AI" or whatever, is certainly a direction developers could begin exploring, but is probably going to take way too much time and way too much ongoing maintenance cost, for way little advantage. I'm not a fan of this direction. > > Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Still a lot of work, but at least more reliable, with less ongoing maintenance cost, and potentially can be supported by other terminals too. > > Similar story for other ideas you had in mind, e.g. sure a terminal could try to understand when a command was started and when it completed, but it'd be extremely fragile. Or it could be properly designed and then explicitly implemented in relevant apps. Both approaches are extremely costly in terms of developer efforts. The reply to that comment is about making the progress display in the Tab itself. If it can display in there, it could also be displayed in a Status Bar. Anyway, the original concept teaser design has a Status Bar, and my point is more about where that status bar is rendered. If there is a real lack of things to put in a status bar, then it could be opened up to extension programmers. Even a looping gradient or fun ASCII animation could be enough reason for a bar.

claunia commented

@zadjii-msft commented on GitHub (Nov 7, 2019):

I can't tell y'all how many times @DHowett-MSFT and I have had the exact same discussion with @bitcrazed on this subject 😋

@zadjii-msft commented on GitHub (Nov 7, 2019): I can't tell y'all how many times @DHowett-MSFT and I have had the exact same discussion with @bitcrazed on this subject 😋

claunia commented

@egmontkob commented on GitHub (Nov 7, 2019):

my point is more about where that status bar is rendered.

There are plenty of great UI proposals for that. My point is: where will you get the data to be displayed there? It's an extremely hard question.

it could be opened up to extension programmers.

Could be? Yes. Should be? I'm really not convinced. How many programs would use it? Probably hardly any.

Even a looping gradient or fun ASCII animation could be enough reason for a bar.

I firmly disagree. Invent a new escape sequence, a quasi new standard, allocate screen real estate (and preferably make a promise that it'll stay there forever), just to see an app or two do some fun ASCII animation? I would definitely not do this.

@egmontkob commented on GitHub (Nov 7, 2019): > my point is more about where that status bar is rendered. There are plenty of great UI proposals for that. My point is: where will you get the data to be displayed there? It's an extremely hard question. > it could be opened up to extension programmers. Could be? Yes. Should be? I'm really not convinced. How many programs would use it? Probably hardly any. > Even a looping gradient or fun ASCII animation could be enough reason for a bar. I firmly disagree. Invent a new escape sequence, a quasi new standard, allocate screen real estate (and preferably make a promise that it'll stay there forever), just to see an app or two do some fun ASCII animation? I would definitely not do this.

claunia commented

@j4james commented on GitHub (Nov 7, 2019):

Or, another approach could be to invent some new escape sequence, and patch applications to emit that.

Or, as I mentioned before, you could support some of the existing sequences: DECSSDT, DECSASD, DECLTOD.

@j4james commented on GitHub (Nov 7, 2019): > Or, another approach could be to invent some new escape sequence, and patch applications to emit that. Or, as I mentioned before, you could support some of the existing sequences: [`DECSSDT`](https://vt100.net/docs/vt510-rm/DECSSDT.html), [`DECSASD`](https://vt100.net/docs/vt510-rm/DECSASD.html), [`DECLTOD`](https://vt100.net/docs/vt510-rm/DECLTOD.html).

claunia commented

@DHowett-MSFT commented on GitHub (Nov 7, 2019):

For progress specifically, that'll be this:

I could have sworn we had an internal issue for this feature, but it never got migrated to github it appears....

FOUND IT! MSFT:18258406. Here are the relevant notes:

sequence description

ESC ] 9 ; 4 ; st ; pr ST Set progress state on Windows 7 taskbar and ConEmu title. When st is 0: remove progress. When st is 1: set progress value to pr (number, 0-100). When st is 2: set error state in progress on Windows 7 taskbar

It's nonstandard, but so go most OSCs. 😄

@DHowett-MSFT commented on GitHub (Nov 7, 2019): For progress specifically, that'll be this: > I could have sworn we had an internal issue for this feature, but it never got migrated to github it appears.... > > FOUND IT! MSFT:18258406. Here are the relevant notes: > > | sequence | description | > |------------|------------| > | `ESC ] 9 ; 4 ; st ; pr ST` | Set progress state on Windows 7 taskbar and ConEmu title. When st is 0: remove progress. When st is 1: set progress value to pr (number, 0-100). When st is 2: set error state in progress on Windows 7 taskbar | It's nonstandard, but so go most OSCs. :smile:

claunia commented

@egmontkob commented on GitHub (Nov 7, 2019):

Isn't OSC 9 the desktop notification of iTerm2, or something like that?

@egmontkob commented on GitHub (Nov 7, 2019): Isn't OSC 9 the desktop notification of iTerm2, or something like that?

claunia commented

@DHowett-MSFT commented on GitHub (Nov 7, 2019):

Looks like it is, yep!

@DHowett-MSFT commented on GitHub (Nov 7, 2019): Looks like it is, yep!

claunia commented

@Jaykul commented on GitHub (Mar 24, 2023):

The things that are really worth having on a status bar are things that the shell doesn't know about, like the zoom level, or that change during the execution of a command, like "how long has this command been running" or "what input has been typed" (because it might not have been read by the process yet) ... or the current input/output encoding.

I'm sure a case can be made for additional controls, like maybe a slider for changing the window opacity or zoom level, or a button to send CTRL+C, or to open the command palette...

But yes, a lot of people would take information that would be better in your prompt (so there's a record of it left behind in the buffer) and happily see just the current value in the status bar instead...

Current directory
Git branch
Current user
Console encoding
Date and time
Duration of the previous command.

@Jaykul commented on GitHub (Mar 24, 2023): The things that are really worth having on a status bar are things that the shell doesn't know about, like the zoom level, or that _change **during** the execution_ of a command, like "how long has this command been running" or "what input has been typed" (because it might not have been read by the process yet) ... or the current input/output encoding. I'm sure a case can be made for additional _controls_, like maybe a slider for changing the window opacity or zoom level, or a button to send CTRL+C, or to open the command palette... But yes, a lot of people would take information that would be better in your prompt (so there's a record of it left behind in the buffer) and happily see just the current value in the status bar instead... 1. Current directory 2. Git branch 3. Current user 4. Console encoding 5. Date and time 6. Duration of the previous command.

claunia commented

@mdtauk commented on GitHub (Mar 24, 2023):

In the spirit of the customisation encouraged with Terminal - how about allowing the user to choose what appears in a status bar?

You could use a shorthand for various content and then display what is chosen.

@mdtauk commented on GitHub (Mar 24, 2023): In the spirit of the customisation encouraged with Terminal - how about allowing the user to choose what appears in a status bar? You could use a shorthand for various content and then display what is chosen. ![image](https://user-images.githubusercontent.com/7389110/227506122-4177757b-2480-4d9b-98cf-ce39610c6ae7.png)

claunia commented

@DHowett commented on GitHub (Mar 24, 2023):

I don't disagree that the status bar could be used to display things the shell doesn't know. However, it also cannot be used to display things the terminal doesn't know.

Unfortunately, that includes things like...

the working directory
how long a command has been running after having been spawned by the shell
the output codepage of the connected application
the current user¹

I mean, it could display your current login user... but it can't know that when I ssh foo my username goes from being Dustin to being dhowett. ↩︎

@DHowett commented on GitHub (Mar 24, 2023): I don't disagree that the status bar could be used to display things the shell doesn't know. However, it also cannot be used to display things the _terminal_ doesn't know. Unfortunately, that includes things like... - the working directory - how long a command has been running after having been spawned by the shell - the output codepage of the connected application - the current user[^1] [^1]: I mean, it could display your current login user... but it can't know that when I `ssh foo` my username goes from being `Dustin` to being `dhowett`.

claunia commented