moveToScreen stopped working

[gwwa...@gmail.com]

After upgrading to 0.9.83 (and also to 0.9.84) moveToScreen now gives me this message:

window:moveToScreen(): screen not found: Color LCD

I did a hs.screen.allScreens()[1] (in the console) and it returns Built-in Retina Display, so I went and fixed my code to use the new name. The new name does not work either.

Here is my lua code: https://github.com/gwww/dotfiles/blob/master/.config/hammerspoon/application-watcher.lua#L16 (it is the old screen name).

[gwwa...@gmail.com]

So I've done a bit more sleuthing, including looking at the source code. I couldn't spot anything in the changes (I looked back to ~January), but it did clue me in to a change (https://github.com/Hammerspoon/hammerspoon/commit/067b6ab5a7e20e300e7a0fe7b69d48a56b52fb16#diff-6d0979162e2d13a269fa2862c22e035dc30e925fcfa01b5c07f0512aa5e11909).

Here is what I've narrowed it down to, console log, it would appear the Lua find here: https://github.com/Hammerspoon/hammerspoon/blob/master/extensions/screen/init.lua#L85 doesn't work. Doesn't like the "-" in the screen name.

> hs.screen.allScreens()[1]
hs.screen: Built-in Retina Display (0x6000013644f8) -- in 0.9.82 this used to return "Color LCD" as the screen name

> hs.screen.find("Built-in Retina Display")
(nothing printed in response to this find)

> hs.screen.find("Built")
hs.screen: Built-in Retina Display (0x6000013741b8)

> hs.screen.find("built-in")

(nothing printed in response to this find)

> hs.screen.find("in")
hs.screen: Built-in Retina Display (0x6000013bf6b8)

Here's a PR to fix: https://github.com/Hammerspoon/hammerspoon/pull/2732

[Diego Zamboni]

The dash has a special behavior because the argument to hs.screen.find is interpreted as a Lua pattern, not a plain string. In Lua pattern syntax, the dash means "zero or more".

Note that this is documented in http://www.hammerspoon.org/docs/hs.screen.html#find:

• a string pattern that matches (via string.match) the screen name as per hs.screen:name() (for convenience, the matching will be done on lowercased strings)

Your patch changes the semantics of the match by enabling the "plain text" argument to string.find. I don't think this is a good idea, but if accepted, this needs to at least be documented. I find it more useful to accept patterns.

--Diego

--
You received this message because you are subscribed to the Google Groups "Hammerspoon" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hammerspoon...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hammerspoon/fb3ab566-273e-4b59-b3f1-2b39615602c3n%40googlegroups.com.

[gwwa...@gmail.com]

I agree. I missed that in the documentation. I'll withdraw the patch.

[Bruno Silva]

Hi,

I'm new here. I would love to try this feature since it would be great for my workflow. Is it possible to share the code and some instructions get it work.

Thanks

BS