MacOS: set_tab_title does not work when launced from spotlight

[jacwah]

When I launch /Applications/kitty.app from Spotlight, my set_tab_title mapping does not work. The screen and OS window title flash, and are immediately restored to whatever they where before. When I launch kitty from inside itself with kitty (/Applications/kitty.app/Contents/Frameworks/kitty/kitty/launcher/kitty), or if I launch it from Terminal.app with open /Applications/kitty.app or open -a kitty, set_tab_title works as expected.

This is weird and I don't know how to debug it. Any ideas? Whatever set_tab_title does seems unrelated to how Kitty was started.

[kovidgoyal]

probably something else is taking over the key binding. try using a different one or look in console.app to see if anything is logged.

[jacwah]

It is not the key binding. When I press the bound key, the UI flashes as if the prompt is shown and then instantly disappears. I verified by using another mapping. Console.app also does not give anything obvious. At startup, when launched from Spotlight I get a "AEGetDescData of non-desc type 'reco' not a good idea", and when launched with open -a I get a "[PARSE ERROR] Unknown OSC code: 7", but I don't think these are related.

[kovidgoyal]

That would imply the kitten used to ask for the title is failing. Is
kitty actually present in PATH when running from spotlight and does
running

kitty +kitten ask

work?

[jacwah]

$ which kitty
/Applications/kitty.app/Contents/Frameworks/kitty/kitty/launcher/kitty

And kitty +kitten ask shows the dialog correctly.

[kovidgoyal]

then I am out of ideas, I cannot replicate on my mac. You can try adding some debug prints in the kitten and the code to launch it (just grep for set_tab_title) to see where it is failing. Using the log_error function which will log to console.app

[kovidgoyal]

actually testing PATH/running kitty from inside a shell is not a sufficient test, since the shell could be modifying PATH. Try setting your shell in kitty.conf to something like the following script:

#!/usr/bin/python
import os
from shutil import which
print(which('kitty'))
input(os.environ['PATH'])

that will display the actual PATH seen by kitty rather than the PATH inside your shell

[jacwah]

Both launching from Spotlight and from a shell yields /Applications/kitty.app/Contents/Frameworks/kitty/kitty/launcher/kitty and has /Applications/kitty.app/Contents/Frameworks/kitty/kitty/launcher in PATH.

When I get some time I'll try debugging it more properly.

[ptbrowne]

I have the same problems as jacwah, I think it started when I compiled kitty on my machine.

Only difference with jacwah is that for me, ask does not work.

kitty +kitten ask
fish: 'kitty +kitten ask' terminated by signal SIGSEGV (Address boundary error)

[kovidgoyal]

Yeah I'm pretty sure the issue is different kitty binaries conflicting.
Remove the compiled kitty completely and re-install the released one and
see if it fixes it.

[ptbrowne]

Sorry for the delayed response. I had a kitty inside my ~/bin/ directory and it was clashing. Big thanks !

[kovidgoyal]

I'm closing, since I am fairly sure this a PATH related issue with multiple confilicting kittys. Feel free to update the issue if you have evidence to the contrary.

[ptbrowne]

I'm closing, since I am fairly sure this a PATH related issue with multiple confilicting kittys.

Wouldn't it be possible for the kitty instance to know which binary it has to use not to have any conflict ?

Instead of having a blink screen and nothing, maybe a message with "Couldn't start the tab title setter, you may have conflicting kittys, check your PATH", and link to this issue ?

[kovidgoyal]

No, it is not possible, since kitty is designed to run in multiple ways, as a binary, an app, standalone, spread into the filesystem, etc. And in any case since the vast majority of kitty users are not going to be having two kitty installs, this is not that important an issue.

[kovidgoyal]

actually for the aprticular case of running from an app bundle, it can be done.