Hammerspoon: Double-Clicking an Installed Spoon Deletes It

[roeybiran]

Steps to reproduce:

1. Install or put a spoon in ./Spoons.
2. Double click or open it.
3. You’ll see this message:
   
4. The .spoon is removed immediately — it doesn’t go to the trash.

And, a question:
Is it possible to make Hammerspoon/macOS/Finder stop treat .spoons as packages, but as the folders they are? It would make their management much easier for me, for example opening them directly as folders with launchers such as LaunchBar.

Edit: my ./hammerspoon directory is symlinked to ~.

Thanks!

[luckman212]

I don't think there's any way to force Finder to treat .spoon packages as regular directories, short of modifying the Info.plist file inside the Hammerspoon app bundle. LaunchServices controls this pretty exclusively. Spent a few hours researching it, but came up empty.

As for the spoon being deleted if double-clicked when it's already installed—that seems like just a straight up bug.

[cmsj]

Yeah that’s definitely a bug. It’s a weird one too, because we’re supposed to have already fixed this: https://github.com/Hammerspoon/hammerspoon/blob/master/Hammerspoon/MJAppDelegate.m#L56

[latenitefilms]

@cmsj - Maybe related to sym-links? @luckman212 mentions here that his Hammerspoon config is a sym-link so we might need to resolve aliases first?

[latenitefilms]

Maybe helpful?

https://www.cocoawithlove.com/2010/02/resolving-path-containing-mixture-of.html

[roeybiran]

Thanks for the replies everyone!

Indeed, I forgot to mention that my ./hammerspoon is entirely symlinked to ~, from elsewhere on the system. This is probably the root cause of the issue, but it would be great if there would be away to disable this behavior regardless (or at least move the .spoon to trash instead of outright deleting it).

[luckman212]

I don't symlink the whole ~/.hammerspoon dir — just the files contained within. This way I can keep my HS configs in a centralized repo (~/Sync/Settings/Hammerspoon/), but still have a custom init.lua per-machine since I use different modules and keybinds on desktop vs laptop etc.

My ~/.hammerspoon/Spoons directory, however _is_ a symlink. So I'm facing the same bug as @roeybiran.

When I tested this with my Console open, I get the following 2 errors:

Spoon already exists at /Users/luke/.hammerspoon/Spoons/HSKeybindings.spoon, removing the old version

followed by

Unable to move /Users/luke/Sync/Settings/Hammerspoon/Spoons/HSKeybindings.spoon to /Users/luke/.hammerspoon/Spoons: Error Domain=NSCocoaErrorDomain Code=4 "“HSKeybindings.spoon” couldn’t be moved to “Spoons” because either the former doesn’t exist, or the folder containing the latter doesn’t exist." UserInfo={NSSourceFilePathErrorKey=/Users/luke/Sync/Settings/Hammerspoon/Spoons/HSKeybindings.spoon, NSUserStringVariant=( Move ), NSDestinationFilePath=/Users/luke/.hammerspoon/Spoons/HSKeybindings.spoon, NSFilePath=/Users/luke/Sync/Settings/Hammerspoon/Spoons/HSKeybindings.spoon, NSUnderlyingError=0x600003abc060 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

This condition in MJAppDelegate.m@L56 is definitely not being hit...

if ([dstSpoonFullPath isEqualToString:fileAndPath]) { ...

Seems like, as @latenitefilms pointed out, it would help to resolve the real path to MJConfigDir() with stringByResolvingSymlinksInPath before the comparison is made, something like (I'm not an objc programmer, forgive me):

NSString* MJConfigFileFullPath(void) {
  return [MJConfigFile stringByResolvingSymlinksInPath];
}   

I compiled a test build against this PR #2359 and it fixed the bug for me. There's still an edge case: If your "Spoons" directory isn't in the same real path as your init.lua you'll still end up in a hole. I.e. if you have a layout like this:

~/.hammerspoon (real)
~/.hammerspoon/init.lua (symlink)
~/.hammerspoon/Spoons (real)

I don't think that would be too common, so I didn't try to solve for it, but I imagine it wouldn't be too difficult.

[cmsj]

Thanks @luckman212 for the PR, we should be good on this issue from the next release.