Kitty: 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.

[ptbrowne]

Thanks !

On 14 January 2019 at 05:03:25, Kovid Goyal ([email protected])
wrote:

Closed #1280 https://github.com/kovidgoyal/kitty/issues/1280 via c247a6c
https://github.com/kovidgoyal/kitty/commit/c247a6c0cc96a8a2d6f26bcc67484886ac5359b5
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kovidgoyal/kitty/issues/1280#event-2070918394, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAcaruT9d8mIZRizAyvaGV0GozbBTprRks5vDAGNgaJpZM4Zk_aA
.

[sheriferson]

I'm running into this issue on Mac (sounds exactly as described in the initial issue description):
Kitty installed using brew cask install kitty works just fine. Keybindings to change tab title, or search/enter unicode symbol work perfectly. But using compiled kitty.app shows the broken behavior.

The following reproduces the exact issue to me:

• brew cask uninstall kitty (make sure there is no longer a kitty.app in /Applications)
• Clone kitty master branch, run make app
• Copy the generated kitty.app in the repo folder to /Applications
• Launch that compiled kitty.app. Keybindings make the UI flash but not do anything.
• If, from that malfunctioning window, I run kitty to open another kitty window, that new window works fine. The keybindings work again.

Some more information:

• kitty +kitten ask does work. It shows a prompt and echoes back a dict of the string I entered.
• If I open Terminal.app and go to /Applications, then run open kitty.app, the keybindings work fine. But I see "[PARSE ERROR] Unknown OSC code: 7" in the original Terminal.app window.
• The same happens if I navigate to "/Applications/kitty.app/Contents/Frameworks/kitty/kitty/launcher" and run ./kitty.
• If I go to /Applications in Finder and launch kitty.app by double-clicking kitty.app or using Command+O, the keybindings do not work.
• I vaguely remember at some point seeing a kitty error/warning about permissions to some file inside the bundled kitty.app, but I am not sure how to reproduce that.
• I've looked for any other conflicting kitty binaries and can't find any.

Let me know if I can do something to help debug this, or if I should open a new issue.

[kovidgoyal]

All you need to do is make sure the only kitty in your PATH (and this is the system wide PATH) not the path inside a shell points to the kitty inside whatever kitty.app bundle you are using, and you will be fine. The ssues you describe happen when there are multiple kitty executables ont he system and the wrong one is getting picked u.

[sheriferson]

I tried searching for any other kitty files on the whole machine and could only find the two inside the bundle:

cd /
sudo find ./ -type f -name "kitty"
.//Applications/kitty.app/Contents/Frameworks/kitty/kitty/launcher/kitty
.//Applications/kitty.app/Contents/MacOS/kitty

I'm not sure where else there could be one that wasn't found with that command above.

And why would that cause the issue to happen when double-clicking the /Applications/kitty.app file in Finder, but not when launching the exact same bundle from Terminal via open kitty.app?

This might be naive investigation, but I think there might be a slight difference in how the bundle is prepared via compiling vs how Homebrew does it.

Specifically, the executable kitty installed via Homebrew has extended attributes:

xattr -l /Applications/kitty.app/Contents/MacOS/kitty 
com.apple.quarantine: 01c1;5c4624c8;Homebrew\x20Cask;A6F39B74-00B9-47F6-9CE4-46D14760B4DB

whereas the one in the compiled bundle does not. There is also a Contents/_CodeSignature directory with Homebrew Cask but not in the compiled bundle.

I vaguely remember that Finder does some checks on the quarantine extended attributes of applications that Terminal.app doesn't when launching the same app. Again, I could be away off, but I can't think of what else is different between brew cask install kitty and just replacing that with the manually compiled bundle and deleting the repo directory to make sure there are no other executable kitty files on the system.

Edit to add: I'm running Mac OS 10.12.6 (High Sierra) for what it's worth.

[kovidgoyal]

Because the PATH inside Terminal.app and the one seen by launch services is different. So depending on how you launch kitty, it will see different values of PATH. So I'm guessing the PATH in your Launch services environment does not include wherever python3 is installed.

Quarantine attributes apply only for downloaded software and are tested by Gatekeeper when launching downloaded programs They dont apply for locally built software. Similarly code signatures are not required for locally built software.

[kovidgoyal]

See https://github.com/kovidgoyal/kitty/commit/cab1ba4e501083f597847b9e5a910151e6ea8d61

@Luflosi could you please test this, I dont have a macOS machine available to do so.

[sheriferson]

On my end I just tested with the latest commits from master and can confirm that it fixes the issue – at least on this machine I'm using right now. Everything works just as it did with the brew cask version.

Thanks Kovid :)

[Luflosi]

This fixes a few issues for me as well. I can now start kitty with python3 . and have it properly take the focus from the last window. The unicode input kitten now works instead of crashing, when I have python3 installed via nix. I'm looking how I can apply the same fix to the asan-launcher. I'll make a pull request when I figured it out.

[Luflosi]

Why is there a separate launcher just for asan? Could the two launchers be combined?

[kovidgoyal]

because it has to link against libasan

[Luflosi]

After a bit more testing, it looks like I was mistaken when I said, that this patch made python3 . work for me. python3 . works when python3 is installed via home-brew but doesn't, when it's installed via nix. But what I wrote about the kitten is true.

[kovidgoyal]

This patch affects only the kitty executable that is linked against
python. It has no effect on python3 .