This is another chooser menu. The world doesn't really need another chooser. But it's mine. I
used to use dmenu then xmenu and that was fine. I wish it still were fine. Unfortunately,
these days macOS prevents another app from foregrounding itself while a NSSecureTextField has focus,
which is fair enough. However, this breaks the old-fashioned flow of using Hammerspoon to bind a
keyboard shortcut to run a script which does something like pass show $(xmenu $options).
This crappy little utility steals just enough inspiration from Hammerspoon to be able to show a chooser whenever it wishes, from a global hotkey. The only reason i moved away from the perfectly feasible solution of v0.2.0 which still needed Hammerspoon was that the whole thing took a few hundred millis to display, which is lame. This is instantaneous.
I think i need to go away and take a few consecutive showers.
Here's a screenshot:
Special thanks to the fine folks behind The Ultimate Oldschool PC Font Pack.
- This probably doesn't suit anyone else's preference. That's fine.
- We split search terms on whitespace, we don't worry about literal spaces in candidates.
- Some substrings are very popular, but i still want to be able to match on them.
- For example, in a list containing "foozoo.com" and "zoo.com.au", searching for "zoo." should surface zoo.com.au first, not foozoo.com, even though the latter is lexicographically earlier.
- The logic is that the first search term is treated specially:
- If inputting "asdf jkl", we anchor "asdf" at the start and "jkl" anywhere after "asdf". Et cetera for subsequent filter words (i.e., "a b c" will find a candidate called "abc" but not one called "a c b", because order of filter words is important).
- After the first "strict" round, we redo the search, but without caring whether the first filter word is the prefix of the entry or not.
- Of course, we present a unique'd list of results.
Hammerspoon is able to show a chooser on keypress (e.g. for emojis), even when a secure text entry field is visible. The short version is that's because it's an NSPanel and not an NSWindow. That was a whole rabbit hole.
As for the Accessibility bit - sometimes the app boots and just doesn't seem to have accessibility enabled. As our friend with his now-404 blog mentions in tmandry/AXSwift#21, you sometimes need to remove and re-add the app in the Security & Privacy panel. Bit of a gotcha, too.