activating VimMode screws up windows management with Magnet

[godbout]

i use Magnet to handle my windows. after i've installed VimMode.spoon, on my iMac, my window placement gets screwed up. there's some animation happening and some shortcuts don't cycle in a right order. but things are fine on my MBP, same set up. the only difference i see is on my iMac, Hammerspoon load the screen extension. this doesn't happen on my MBP. this seems to be loaded when i call local vim = VimMode:new() in my init.lua. any idea what's happening? i couldn't find a way to disable the screen extension.

my windows get screwed only at first launch though. if i close, and launch again, then Magnet handles ok. in the console i have a message that Hammerspoon couldn't start a watcher. at first start, when it screws my windows, the message doesn't show.

let me know what info i can give. thanks!

[dbalatero]

The screen extension is used to determine the current text input I believe, so it is required.

Hm, Magnet costs money so it's harder for me to test locally as I do not have a license.

In general there is some interaction with some window managers and this library that is opaque to me. I'm not clear what causes it, however. yabai had some kind of similar issue in #45.

[dbalatero]

Is there a way for you to export your Magnet configuration, and describe exactly what shortcuts are not cycling, and what order you expect vs what order you see? Record some GIFs with QuickTime Player?

[godbout]

ah! thanks for the quick answer. i'll look at the answers in #45.

i'm gonna record some GIFs. for the Magnet config, unfortunately there's not much i can export.

i'll try to explain as clearly as i can with the GIFs. #45 seems to be a similar issue yes.

[godbout]

let me know if you can see this, should work on macOS: https://share.getcloudapp.com/DOu9780k
if yes, i'll make videos instead of GIFs. better, and even smaller!

edit: this is the normal behavior.

[godbout]

this is the behavior after Hammerspoon and VimMode is on: https://share.getcloudapp.com/5zuwlyzP

basically my shortcuts (currently ctrl+option+[ and ctr+option+] but i've tried others and the results are the same) to push the windows half left and half right on the screen don't work. rather than pushing the windows to those sides, they seem to be cycling through the past moves (pushing to quarters).

edit: sorry, not easy to explain. but there's definitely something playing with the windows.

[godbout]

comment line 69 as said in #45 doesn't help in my case.

[dbalatero]

@godbout Ok great. I can see the video thanks!

One more thing - paste your entire init.lua config?

[godbout]

here you go

local VimMode = hs.loadSpoon('VimMode')
local vim = VimMode:new()

vim:bindHotKeys({ enter = { {'cmd'}, 'escape' } })

vim
  :disableForApp('Sublime Text')

pretty straightforward. i'm all new to Lua, and Hammerspoon. was trying to get an OS wise Vim mode :))

[godbout]

btw, is there any way to bind entering normal mode to Capslock + Return?

in ST or Xcode i go to normal mode with Capslock, that is bound to Escape actually through macOS itself. then i have a few stuff through Karabiner like Escape + hjkl to move, but it's not very nice. i'm trying to get something similar to my Capslock, but to start VimMode.spoon command mode. currently i'm binding to Cmd+Capslock, but if possible i'd rather go for Capslock+Return. if i get this correctly Hammerspoon can't handle this kind of combination and that should be done in Karabiner, right?

[godbout]

not sure if related, but i saw this on vimac gh: nchudleigh/vimac#78

talking about breaking windows positioning and sluggish behavior with windows manager tools including Magnet, and references issues with AXEnhancedUserInterface and AXWindow. in case that rings a bell!

[godbout]

if there's anything else i can do to help let me know. i know nothing in Lua currently, but i code. and always willing to learn.

[godbout]

sorry to post again here if it's not the right place. i had a look at the source and i was playing around trying to add the inner motion like in ciw, dip etc... am i wrong or this might need a major rewrite of the Spoon?

[fuelingtheweb]

I'm seeing this issue as well with this window management spoon: https://www.hammerspoon.org/Spoons/WindowHalfsAndThirds.html

In fact, simple calls to hs.grid like hs.grid.set(hs.window.focusedWindow(), '2,0 8x4') don't behave properly.

When I have VimMode enabled (or vim.hotPatcher:start() specifically), my window movements don't behave as expected. There's not really a consistent behavior. The window just moves and resizes in a way that is not intended.

[dbalatero]

@fuelingtheweb Ok cool! Just to clarify, when you have hotPatcher:start() disabled, do things work?

VimMode.spoon/lib/utils/ax.lua

Lines 45 to 60 in 48f01ee

	axUtils.patchCurrentApplication = function()
	local currentApp = hs.application.frontmostApplication()
	-- cache whether we patched it already by app name and pid
	-- pray for no collisions hahahahahhahaha
	local patchKey = currentApp:name() .. currentApp:pid()
	if alreadyPatchedApps[patchKey] then return end
	alreadyPatchedApps[patchKey] = true
	local axApp = ax.applicationElement(currentApp)
	if axApp then
	patchChromiumWithAccessibilityFlag(axApp)
	patchElectronAppsWithAccessibilityFlag(axApp)
	end
	end

I'm thinking that I'm flipping flags too generally, and I should probably detect Chrome (to turn on the Chrome flag) and Electron apps (to turn on the AXManualAccessibility flag).

If I make a branch can you help me test it?

[dbalatero]

not sure if related, but i saw this on vimac gh: nchudleigh/vimac#78

Ick, I looked at this issue. I'm damned if I do, damned if I don't:

• if I stop patching AXEnhancedUserInterface into Chrome, then Chrome doesn't get advanced mode motions for many input fields
• if I keep patching it in, it breaks window managers for some reason

[dbalatero]

I'm thinking about two options:

1. Disable auto-patching Chrome for everyone, and make it opt-in.

This is safest, but it also makes the out of the box experience worse for anyone not using a fancy window manager. I have no numbers on what percentage of people do or don't use things like Magnet, but my gut says that:

• generally people don't use them
• people that use software like VimMode.spoon probably bias more towards windowing managers

2. Make the hot patching opt-out

This is potentially better out of the box, and still allows folks to opt out of the accessibility patching by doing something like vim:disableBrowserAccessibilityPatching()

I could provide some kind of warning if you're using Magnet/yabai/[insert manager here]. Surfacing that warning could take a few forms:

• Hammerspoon console warning - easy to miss
• hs.alert.show - giant warning, kind of annoying, you might want to opt out of the warning text

---

I'm leaning towards option #2, with a silence-able hs.alert that redirects the user to look at the Hammerspoon console for more information. Thoughts?

[fuelingtheweb]

@dbalatero First off, I'd be happy to help you test any updates.

Regarding commenting out hot patching, I actually needed to comment out vim.hotPatcher = createHotPatcher() in addition to vim.hotPatcher:start() to fully eliminate the window management issue.

With hot patching commented out, VimMode seems to be working as usual. I originally thought disabling hot patching was causing some oddities in VimMode, but those seem to be present with hot patching enabled. For example, VimMode in Finder or Alfred doesn't really work at all. VimMode in the Notion desktop app works pretty well, but some of the features that I want to use the most like selecting inside quotes (vi") and jumping to things like quotes (f") don't work at all. In my testing, things worked the best in Chrome even if hot patching was disabled.

[dexterleng]

@dbalatero

Another solution would be to submit a patch to Chromium to allow enabling accessibility through another attribute that is not AXEnhanceUserInterface. Electron apps use AXManualAccessibility which works out fine.

I filed an Issue [1] with Chromium suggesting this, they seem open to the idea, but I can't submit a patch because my computer doesn't have enough disk space or compute to build Chrome to test out. Perhaps you could look into this?

[1] - https://bugs.chromium.org/p/chromium/issues/detail?id=1127357
[2] - nchudleigh/vimac#78

[dbalatero]

Yeah that sounds good to me! I have a lot of compute over here. Let me look into building Chrome first, and then maybe I can hit up a co-worker that used to work on Chromium to get some help with the patch.

[dexterleng]

Awesome! I looked at the code a while back, it should be a pretty simple change:

from

if ([attribute isEqualToString:@"AXEnhancedUserInterface"]) {

to

if ([attribute isEqualToString:@"AXEnhancedUserInterface"] || [attribute isEqualToString:@"AXManualAccessibility"]) {

https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/chrome_browser_application_mac.mm;l=331?q=AXEnhancedUserInterface&ss=chromium

[dbalatero]

Ooh even better. One snag is that I'm on a Hackintosh running macOS 10.14 and the install instructions for Chromium dev say 10.15 minimum. I'm going to ignore that and see if it still works.

[dbalatero]

Update - build failed on my Mojave machine. I'm also blocked from testing this patch pending an upgrade of my Hackintosh to Catalina which I dread… anyone want to be a hero and try the patch that @dexterleng suggested above and test a build out?

[dexterleng]

Turns out the Rectangle window manager handles this weird case. rxhanson/Rectangle#285

[dexterleng]

Hmm, I think AX apps that want to support non-native apps like Chrome have a few options (or a combination of them):

• Support enabling AXEnhancedUserInterface, warn them about window positioning and ask them to use Rectangle
• Support AXManualUserInterface, and ask them (or do it ourselves) to extend applications to support AXManualUserInterface (which is kinda unpleasant and doesn't scale)
• Somehow get Apple to fix the damn attribute, which I'm not optimistic about since this is a known issue for very long.