which makes cmd-r in xcode take a long time for no reason. Should figure out how to make this better - have the Makefiles actually know about all the invidual targets?

gdoc says 'Chris', and I'm fine with this. Alternatively an 'organisation' cert might make sense. We can indeed revisit this later.

We should give some useful hints, up to and including the sqlite trick from http://mizage.clarify-it.com/d/6ervmn

It's annoying me. We can probably use the same weak import trick that is used for the newer Accessibility API in the same file, to get rid of the build warning. Maybe. Worth a shot and will guard us against the point where AXAPIEnabled is removed, probably.

Normal users ('the 99%') will make do with the modules we include, and will not have to bother with brew or rocks or whatever.

For the rest, being developers, and users who want beta stuff, we need to document how to submit and how to use third party mods. Probably comes down to how Mjolnir works right now for all modules.

as a matter of standard module practice, should the act of simply requiring a module have immediate side-effects? In particular, I noticed it cause an alert to pop up just from requiring it, but this could apply to other things as well: setting hotkeys, etc.

We need finer grained control of the extension build process, so let's have build_extensions.sh just call make in each directory and collect their outputs.

in Travis?

I would recommend using mjolnir._asm.ui.notification (https://github.com/asmagill/mjolnir_asm.ui) over mjolnir._asm.notify -- it's backwards compatible and offers more features (and it's primed to add scheduled (dated) notifications to it at some-point as well)... I can do this come the weekend if you'd like.

e.g. when the currently focussed window changes, or when windows appear

Mjolnir has automatic updates, but it's a homegrown sdegutis thing. No idea whether it's any good. Wondering whether we should be using Sparkle?

I'd like to be able to focus a window, check if menu items exist and/or are enabled, and trigger them.

During require 'hs.alert'.

$ nm internal.so | grep luaopen
0000000000003900 T _luaopen_hs_alert

We should probably rename luaopen_hs_alert to luaopen_hs_alert_internal now that the .so is no longer called hs/alert.so.

There must be a way to use make -f with the generic Makefile, and still be able to infer the name of the module within the Makefile itself. Right now it doesn't work because of the first two lines of the generic Makefile.

Some modules (by _asm) require 10.10. Right now, if we simply import those, Xcode forces us to build the whole app with a 10.10 requirement.

Request: figure out how to have 10.10-only modules without forcing the whole app to 10.10. I'm okay with this meaning building requires 10.10, especially after we cover #6 for working on specific modules 'out of band'.

This shouldn't be needed anymore, given Sparkle. Prove that is the case, then drop it.

e.g. when applications launch/exit

Suggested by Bram Heerink

Right now hotkeys take effect when the specified key triggers KEY_UP, but usually the modifiers are still sending KEY_DOWN at that point, which means they are falling through to the focussed window. This can have very surprising side effects.
Perhaps we should look at waiting until the modifiers are released before triggering events, or at least having it as an option.

caffeinate would like this, also probably some other modules.

Allow modules to notify Hammerspoon if a user is using a call that will go away in a future version. Then we can show all of these warnings in a single place in the prefs.

As far as i can see, the only reason ARC is not being used now is that the luarocks build scripts for osx use compiler flags (like supporting old OSX versions) that prevent it. This is not a good reason for not having ARC.

Diffing window.m between Hydra and Mjolnir mostly shows ARC removal, suggesting that in general the changes between ARC and non-ARC are minor.

and figure out whether any of them make sense for us to address before public release.

I have a local backup, current as of 5 minutes ago, of all issues+comments on sdegutis/mjolnir, just in case, and also of the wiki there.

Right now, if there's a typo in setup.lua (not init.lua), the app just sits there.

Slate triggers OSX to present a nice dialog that has a button to enable accessibility access. Figure out how and do the same :)

For the out-of-box experience.

Hey

Please can we have:

www.hammerspoon.org -> CNAME hammerspoon.github.io
hammerspoon.org -> A 185.31.18.133

Normalise all of them, including the odd LICENSE.md ones.

Did we accidentally already choose Hammerspoon? ;)

I think we might have!

Assuming we can even relicense. MIT? GPL?

Should these be part of the default core? If so, I'll issue a pull later today.

Related -- what other modules of mine should be "builtin"? I'll prioritize appropriately.

Soft public

Meaning: make our repo public at hammerspoon/hammerspoon

• Agree that the repo can be flipped to public
• Transfer repo from ~cmsj to ~hammerspoon
• Close #20
• Close #33
• Close #26

Hard public

Meaning: we announce to the mjolnir mailing list.

• hammerspoon.org is up with some content
• README is written
• all other documentation is either gone or correct

Events when joining/leaving a wifi network.
Information about current/available networks

• define procedure for importing and updating third party mods
• invite authors (or just ask for their permission) (or just take their stuff, it's MIT ;) )

(maybe make separate issues for tracking the imports of the third party mods we like, when item 1 is done)

Per https://github.com/CdLbB/fb-rotate/blob/master/fb-rotate.c#L105 to be able to switch which screen is considered the "main" one.

Needed to add the following to Pods-Hammerspoon-environment.h to get io.popen() to work:

define LUA_USE_MACOSX 1

Since lua is being built outside of the Hammerspoon project (unlike Mjolnir), the Hammerspoon.pch file doesn't carry it's defines over. This could go into the pod pch file, I suppose, but since you set some defines for Lua in the .h file, I figure it's as good a place as any.

(Not in a place where I can reliably do my own fork and pull request yet, so I post it here for consideration)

Pending #6

Right now the out-of-box experience is "please write your init.lua". We could offer a button that installs a sensible/fun init.lua that people can start editing. Later on (make a new ticket after closing this one when we have a default config?) we could think about having a wizard.

Fix up doc generation (it's pretty messy now because of all the third party module support). Publish on web. Publish on Dash. Perhaps include with app?

As far as I can see, this would allow us to remove Lua from our git tree without suddenly relying on brew. Also makes it easier to pull in other things (although sadly Sparkle is not usefully present in pods)

Cover things like:

• Needing to use the xcworkspace for the pods to work

• include core modules (#3)
• include 3rd party modules (#4)
• fix up accessibility (#8)
• default config?
• some wizard?
• write getting started doc
• Module discovery is hard - any ideas beyond the above?