Tab icons for jobs

[mnemnion]

Related: #3961

I'm a heavy tabs user, and move them around a lot going between full-pane view on the laptop and split-view on the monitor. I also lean on backgrounding to navigate: ^Z out of nvim, run Zig, back to nvim and so on.

This works so well for me because starship displays background tasks in the prompt. If there's one, it's a blue ◆, two or more is +2 etc, also in blue. That's all configurable of course, but this is the default behavior.

I'm sure it wouldn't be to everyone's taste, but I would love it if I could configure Ghostty tabs to do exactly the same thing. Just a little icon or number to the left of the directory. Ideally this could be a chosen color, but that's not important if it's difficult to provide.

I'd weakly argue that this should be opt-out rather than opt-in. There's always the balance between, on the one hand, "why is Ghostty now doing some new thing and how do I make it go away" vs. users not diligently reading release notes and never knowing that a feature is available.

In fact, I got exactly to the end of the last paragraph before it hit me that, while I did search discussions, I hadn't scanned the option reference to see if I had missed a trick. Looks like no, but I am not in fact one who diligently reads the release notes (sorry to whomever writes them!).

In any case, I think the "I have updated an app and it's doing a new thing I don't like" scenario is fairly straightforward for the kind of technically-oriented user who employs a terminal emulator: read the release notes and find out how to disable it.

• Options (spitballing here):
  • titlebar-show-background-jobs
  • titlebar-show-background-jobs-color
  • titlebar-show-background-jobs-icon
  • titlebar-show-background-jobs-count-threshold this one is a maybe. Starship has it, it will show the icon up to this number and a count over it. Personally I do not see the sense in a value which isn't two, but YMMV.

[jcollie]

This is not something that Ghostty can really do as it doesn't have access to the same information that starship does. Since starship is integrated into the shell, it can query the shell for information like the number of background jobs. Ghostty cannot do that. What can be done is to extend your shell to add the information about jobs to the title. The title is generally set dynamically by the shell (or by programs called by the shell). For a good starting point see the starship documentation.

[jcollie]

I don't think that Ghostty (and Ghostty's shell integration) should become the place to implement all of these features. The current crop of shell integration features in Ghostty are there mostly to work around the lack of support for certain things (like OSC 133 integration) in shells. Recent versions of fish and nu have no need for most of Ghostty's shell integration as they implement them natively. Other shells can use things like starship to enhance their native functionality.

I personally disable all of Ghostty's shell integrations because it's not needed if you use the right version of shells or integrate the functionality in other ways.

[mnemnion]

It would need to be a shell integration, yes.

I don't see how it necessarily follows that it isn't something Ghostty should be capable of. Each tab is a terminal emulator, and every emulator is running a shell. Integrating with the shell doesn't strike me as a design compromise.

Correct me if I'm wrong here: Ghostty takes some level of direct control over displaying the title of the tab. Generally speaking, leaving the available set and read title commands activated is considered a security hazard, which serves as motive to provide that service in a limited way which cannot be exploited.

It follows that something like displaying a job token next to the directory is also best done by Ghostty itself, in cooperation with the running shell, so that the user does not have to leave a security hole open in order to produce the functionality. This does not apply to, in particular, the prompt: but I can't see the prompt when I'm looking at a window full of tabs trying to decide which one I need to select.

If it's possible to write a fish integration which will do the needful, without creating security consequences I would prefer not to endure: then I no longer want Ghostty to provide it directly, I would be happy to take over printing the title myself. That is not my understanding, but if I'm wrong here, it wouldn't be the first time.

Otherwise I would ask that the possibility be more thoroughly considered. As a single unit feature, ideally, rather than as an example of a larger reference class of features which should be excluded as a whole. I don't personally see displaying background jobs in the tab title as a reason why anything additional would need to be added, were that affordance made available.

[jcollie]

This should not be done in Ghostty's shell integration because:

• Adds a lot of configuration to Ghostty for a fairly niche feature (you're the first person to ask for this).
• Adds a lot more complexity to Ghostty's shell integration, which already has to support a bunch of shells (fish, bash, zsh, elvish, nu).
• It's not necessary to implement this in Ghostty's shell integration - Ghostty isn't unique in setting a window title and this is not taking advantage of any other unique Ghostty feature. If this is implemented outside of Ghostty it will work with any terminal emulator that supports setting a window title (which is pretty much all of them).

Here's how I set it up in fish. Doing this for other shells is probably fairly easy. (And no, this is not an argument for doing this in Ghostty's shell integration.)

function fish_title
    set -q argv[1]; or set argv fish
    set j (jobs -p | wc -l)
    echo 👻 🐟 (if test $j -ge 1; echo -n ✦; end; if test $j -ge 2; echo -n $j; end) jeff@home04 — (fish_prompt_pwd_dir_length=1 prompt_pwd) — $argv
end

FYI, Ghostty does not allow setting colors of individual elements of the title.

[jcollie]

And because I configured this directly in my shell, here's how it looks in kitty:

foot:

ptyxis:

alacritty:

[rhodes-b]

Generally speaking, leaving the available set and read title commands activated is considered a security hazard

If it's possible to write a fish integration which will do the needful, without creating security consequences I would prefer not to endure: then I no longer want Ghostty to provide it directly, I would be happy to take over printing the title myself. That is not my understanding, but if I'm wrong here, it wouldn't be the first time.

Writing is no security concern only when reading is involved is when it becomes a problem. At worse its just a bad title when nobody can read
https://ghostty.org/docs/config/reference#title-report