spaces.lua's search for Dock does not succeed on early startup about hammerspoon HOT 3 OPEN

Yeah, it's looking for a running instance of the Dock, so it will fail if Hammerspoon somehow manages to start before the Dock. But all it's actually doing with it at that point is trying to find the Dock app on disk, so I think it could probably be changed to:

    local path   = application.pathForBundleID("com.apple.dock") .. "/Contents/Resources"

(It does try to actually talk to the running Dock later on, to interact with Mission Control/Spaces - but the Dock is likely to be running by the time you're using any of those functions.)

If you want to try out that change, you can copy spaces.lua from Hammerspoon into ~/.hammerspoon/hs/spaces.lua and edit the line above into that copy. Or if you want to dynamically patch it, so that you still get any other updates to spaces.lua in new Hammerspoon versions, you can create ~/.hammerspoon/hs/spaces.lua with this code in it:

local myName, myPath = ...
local pathToAbsolute = require 'hs.fs'.pathToAbsolute
local myAbsPath = pathToAbsolute(myPath)
for entry in package.path:gmatch '[^;]*' do
	local realPath = package.searchpath(myName, entry)
	if not realPath or pathToAbsolute(realPath) == myAbsPath then goto continue end
	local fn = load(coroutine.wrap(function()
		local yield = coroutine.yield
		
		local findStr = [[application.applicationsForBundleID("com.apple.dock")[1]:path()]]
		local replaceStr = [[application.pathForBundleID("com.apple.dock")]]
		
		local findPattern = findStr:gsub('%W', '%%%0')
		local replacePattern = replaceStr:gsub('%%', '%%%%')
		
		local didPatch = false
		for line in io.lines(realPath, 'L') do
			local fixedLine, nMatches = line:gsub(findPattern, replacePattern)
			yield(fixedLine)
			if nMatches > 0 then
				didPatch = true
			end
		end
		if not didPatch then
			print "Warning: couldn't patch spaces.lua!"
		end
	end), '@'..realPath, 't')
	do return fn(myName, realPath) end
	::continue::
end

from hammerspoon.

I've never run into a timing issue this tight, but pathForBundleID should work. At load time, it's looking for the specific verbiage that pages will be using in the Mission Control accessibility objects, so it's the location on disk that matters, not the running Dock itself.

As noted, the running Dock is important when you trigger it, but not at load time.

from hammerspoon.

Would I run into issues if I just edited the app itself for testing?

from hammerspoon.