delay in hs.window.filter

[franzbu]

Due to Sequoia breaking Hammerspoon's dealing with macOS’s spaces, I have been developing an alternative (https://github.com/franzbu/EnhancedSpaces.spoon), in the process of which I have had to work around delays in hs.window.filter when reacting to event triggers.

In my short period of testing, I haven't encountered any issues when reducing the delay for ‘windowMoved’ from 0.5 to 0.01 seconds (local variable ‘WINDOWMOVED_DELAY’ in hs.window.filter). Can you think of reasons why this reduction should be avoided?

When using hs.window.switcher for cycling through the windows of the current mSpace, the filter-related delay of the switcher leads to an issue when cycling through the windows of the current mSpace right after switching over from another mSpace: as due to a delay the filter hasn't triggered the change yet, the switcher cycles through the windows of the previous mSpace. As a workaround, I have used hs.window.switcher’s ‘next’ and ‘previous’ methods for forwarding a table containing the windows I want to use the switcher for. How do you think about the general idea of adding the possibility of using window tables besides window filters to hs.window.switcher?

One last point: for implementing a substitute for macOS’s cmd-tab window switcher, it would be helpful if the hotkey cmd-tab could be overwritten. As other apps such as AltTab achieve this, maybe it can be done with Hammerspoon as well.

Thank you for your time.

[QuantumLibet]

This is great. Thank you.

That said - I wish you hadn't named it SpaceHammer, like the long-standing and well-respected Hammerspoon script named ... spacehammer by agzam. I agree that more knowledgable people could probably just fork it and rename it, but not me.

[franzbu]

Thank you for your feedback; I've renamed it.

[QuantumLibet]

Thank you! This makes it so much easier for me!