yabai rules don't recognize window title set by ghostty

[vaygr]

Steps to reproduce:

yabai -m rule --add app="Ghostty" title="^scratchterm$" scratchpad="scratchterm" grid=5:5:1:0:3:3
open -na Ghostty.app --args --title="scratchterm"

Even though the title is reported correctly once ghostty is launched:

{
        "id":5281,
        "pid":13867,
        "app":"Ghostty",
        "title":"scratchterm",
        "scratchpad":"",
        "frame":{
                "x":12.0000,
                "y":50.0000,
                "w":1488.0000,
                "h":920.0000
        },
        "role":"AXWindow",
        "subrole":"AXStandardWindow",
        "root-window":true,
        "display":1,
        "space":1,
        "level":0,
        "sub-level":-20,
        "layer":"normal",
        "sub-layer":"below",
        "opacity":1.0000,
        "split-type":"vertical",
        "split-child":"second_child",
        "stack-index":0,
        "can-move":true,
        "can-resize":true,
        "has-focus":true,
        "has-shadow":true,
        "has-parent-zoom":false,
        "has-fullscreen-zoom":true,
        "has-ax-reference":true,
        "is-native-fullscreen":false,
        "is-visible":true,
        "is-minimized":false,
        "is-hidden":false,
        "is-floating":false,
        "is-sticky":false,
        "is-grabbed":false
}

But the rule never gets triggered, that is unless I remove title argument for yabai -m rule or set it to ^.*$.

I tested it with kitty to see if it could be yabai's issue, but no, it worked as expected:

yabai -m rule --add app="kitty" title="^scratchterm$" scratchpad="scratchterm" grid=5:5:1:0:3:3
kitty --title "scratchterm"

My assumption is ghostty could be setting the title a bit too late?

[00-kat]

My assumption is ghostty could be setting the title a bit too late?

You're probably correct. There was another discussion about the initial title (which some Linux¹ WMs can report) not being set, and this is likely a duplicate of that. Thanks to GitHub's revolutionary search, I can't find the discussion right now though.

Edit: found it #3606.

Edit 2: based on Pluie's response below, it might not be related to that discussion.

Footnotes

1. It's very likely this happens on macOS too, of course. ↩

[pluiedev]

Ghostty has to wait for the shell integration to report the title, which means that it at least has to wait for the shell to finish initializing and for the shell integration to run. There's gonna be a delay in there.

[00-kat]

This is the title configuration option though, not shell integration... FWIW Kitty sets the title to kitty, then once the shell launches the title gets changed again.

[pluiedev]

Ah. On GTK we unconditionally set the initial title to "Ghostty" first, and then set the title set by the config I think. That could be why.

[00-kat]

I'm not sure if that actually happens with new windows though. When I create a new tab, I can see the title briefly flash as “Ghostty”, but I don't see this when I open a new OS window.

And anyways as the OP noted below, --title makes the shell integration completely irrelevant in the first place.

[vaygr]

Well, I would say this is quite an essential feature for those using tiling window managers.

Does it mean there are no workarounds to be able to distinguish between multiple instances of ghostty on macOS reliably (at startup)? Linux at least has a wm class property.

[vaygr]

@pluiedev also not sure I understand this, but the whole point of --title is to override the value regardless of what the shell reports. At least that's a clear description in kitty's manual. Shouldn't it be treated the same way and, if provided, be initialized as soon as possible?

[00-kat]

At least that's a clear description in kitty's manual.

Ghostty's documentation says this too:

This will force the title of the window to be this title at all times and Ghostty will ignore any set title escape sequences programs (such as Neovim) may send.

[mitchellh]

There is a delay, we set the title asynchronously for Ghostty, but we don't have to. I'll make an issue for it. Whether it fixes your issue or not its probably a good habit.

[mitchellh]

#5934