Resilient auto config loading

[unphased]

I'm still learning hammerspoon API. I've got a config autoreload workflow working solidly now and i'd like to make it robust against all syntax and logic errors inside so that auto reload won't break and need manual re-load if I happen to save the hammerspoon init.lua with a syntax error.

Generally the approach would look something like putting in a try catch around the reload call, and if the load fails, fall back to a load of a config that is known to work (and contains e.g. only config autoreload behavior).

I'll try it out and see how it goes. So far it seems there isn't a way to give an alternate config file path to reload(). But my strategy for this right now is since my config file is already a symlink i'd just retarget this symlink to a known safe config temporarily, and add some more symlink munging logic in the alternate config code. That's all assuming an error in loading could be captured via an exception handler from the original config and the original config would keep executing (feels doubtful so far imo).

[cmsj]

Your hunch at the end there is right - there's no fallback if hs.reload() fails. By the time a Lua error is being thrown from that, the previous Lua instance has been destroyed.

I think the only way to make it truly resilient would be for the auto-reload functionality to be built into Hammerspoon itself, rather than implemented in Lua.

[asmagill]

Off the top of my head, this might be challenging.

You can change the default init script by changing the value of the setting "MJConfigScript", either with hs.settings or defaults from the command line in org.hammerspoon.Hammerspoon, but I think that might only take effect on a restart, not a reload.

And as mentioned above, there is not functionality for "catching" a reload.

You could have the initial init.lua file do something along these lines:

local status, err = pcall(dofile, "testing-init.lua")

if not status then
    print(string.format("testing init file failed with: %s", err))
    print("Loading fallback...")
    dofile("fallback-init.lua")
end

This is just the bare-bones, but the key takeaway is the pcall function which can capture a lua error (but a reload triggers internal actions that terminate the lua state, so pcall can't work on `hs.reload).

Beyond that, yeah, I think @cmsj is right and we'd need some way to syntax check the new files before actually begining the reload process.

[unphased]

I hope this is the right way? i know i need to assign the watcher to a global.

local home = os.getenv("HOME")
local status, err = pcall(dofile, home .. "/.vim/hammerspoon/main-init.lua")

if not status then
    print(string.format("init script failed to pcall with: %s", err))
    -- watcher object must be assigned to global not to get GC'd
    _G.myWatcher = hs.pathwatcher.new(home .. "/.vim/hammerspoon/main-init.lua", function(files)
      -- Use a timer to delay the reload slightly
      hs.timer.doAfter(0.5, function()
        hs.reload()
      end)
    end):start()

    hs.alert.show("Hammerspoon FALLBACK config loaded")
end

[asmagill]

You're correct that the fallback can be included in the standard init file, if it doesn't change much, like your example above.

I was imagining some behind the scenes work to run the "previous" working code (which I can sort of block out in my head, but really isn't a trivial problem in itself), but honestly, this is simpler... include the watcher in the fallback, like you do, and maybe a hotkey or two to pop up the console and/or file editor and it should still keep the work flow clean and moving.

[unphased]

Yea I can progressively add some more known-good basic functionality into the fallback config (incorporating the HS console toggle is a perfect next step) and leave most of the complexity in the main config.

[unphased]

Code is now:

-- Toggle Hammerspoon console. records focused window on open, so may return to the wrong window upon using it to close.
local windowHolder
hs.hotkey.bind("Ctrl-Cmd", "H", function()
    local hspoon = hs.application(hs.processInfo.processID)
    local conswin = hspoon:mainWindow()
    if conswin and hspoon:isFrontmost() then
        conswin:close()
        if windowHolder and #windowHolder:role() ~= 0 then
            windowHolder:becomeMain():focus()
        end
        windowHolder = nil
    else
        windowHolder = hs.window.frontmostWindow()
        hs.openConsole()
    end
end)

local home = os.getenv("HOME")
-- watcher object must be assigned to global not to get GC'd
myWatcher = hs.pathwatcher.new(home .. "/.vim/hammerspoon/main-init.lua", function(files)
    -- Use a timer to delay the reload slightly
    hs.timer.doAfter(0.5, function()
        hs.reload()
    end)
end):start()

local status, err = pcall(dofile, home .. "/.vim/hammerspoon/main-init.lua")

if not status then
    print(string.format("init script failed to launch: %s", err))
    hs.alert.show("Hammerspoon FALLBACK config loaded")
end

~/.vim is my dotfiles repo, adjust your paths accordingly.

[unphased]

So far it's actually been the console toggler and config auto reload functionalities that have taken the most iteration to set up, but I do seem to have them stable now so they can live in here, while this mechanism allows me to hack merrily on main-init.lua and expect it to continue to reload properly even if I screw up in there. Doing it this way also means main-init.lua does not have duplicate code for implementing the above two important functionalities.

Goes without saying, but I'll clarify: inside main-init.lua at the end, I put a hs.alert.show("Hammerspoon config loaded"). So at any time when we save main-init.lua, the content of the alert (whether it says FALLBACK) informs us whether or not there was an error loading that config.