Show HN: Vimac – Productive macOS keyboard-driven navigation
vimacapp.comHello all! I am a student from Singapore who was introduced to Vimium by a friend two years ago. Vimac is my attempt to implement Vimium on an OS level.
I have shared this app on Reddit about a year ago. Since then, the notable changes would be a major performance buff in webkit/electron, force keyboard layout, and reducing the overwhelming no. of hints to what is just "clickable".
It is open source at https://github.com/dexterleng/vimac/.
Do let me know if you have any questions!
Hello!
Glad to see more people making tools around the Accessibility API. I've been working on a similar app called Shortcat (https://shortcatapp.com) almost 8 years ago (wow) but haven't had the time to properly work on it. It sounds like you're encountering a lot of the same problems I've had when I was starting out (figuring what's actionable, forcing keyboard layout etc). Let me know if you want to chat about the various problems in that space
Hey, it’s you! The author of Shortcat. I tried out your project maybe a year ago and absolutely loved the concept, but eventually had to give up on it when it kept crashing and didn’t reliably find what I was attempting to click on. I never knew if Shortcat was to blame or if it was the application not being properly presented to the Accessibility system.
Anyway, Shortcat is a freakin brilliant idea and I hope you keep working on it, or help this author with their project. If you think you’re going to have time to work on Shortcat again, though, I’d happily buy a copy (even if I already did before, I can’t remember if I did) and be an active bug reporter.
Glad you loved the concept!
Unfortunately I've been rather busy the last couple of years and haven't had the capacity to work on Shortcat, and coupled with not being amazing at Obj-C/Swift/Cocoa (my major contributions are FuzzyAutocomplete and the initial POC for Semantic History in iTerm2), being frustrated with building UIs on Mac (mostly build web stuff). There's also the problem that Accessibility APIs aren't well-documented and isn't commonly used, and applications not implementing Accessibility correctly (and potentially causing crashes in Shortcat, or making the target application hang), which was super tough to deal with as a solo dev.
I did have a crack at bringing the Swift-based prototype up to date with Swift 5 on the weekend, and am investigating the feasibility of using SwiftUI which would help me on the UI front! Ideally I'd find another dev to work on Shortcat (rev-share or otherwise), and consider a more sustainable pricing model.
I think tools that depend on Accessibility APIs that are used by people who don't normally depend on Accessibility APIs can force developers to improve their AX implementation so people who do depend on good Accessibility to use applications can benefit.
It makes me happy to hear that it was good enough for you to buy another copy!
How did you discover Shortcat in the first place?
I wish I could remember how I came across Shortcat. It may have actually been simply that your product description matched what I was seeking so perfectly that it turned up on a Google search...or perhaps it was through some second-hand recommendation coming indirectly from a Google search like this one: https://gist.github.com/lornajane/3892c39098cf70baa9c7a1874c...
But the main thing is that Shortcat was simply the thing that I always thought should have been baked into operating systems since the idea of “search to execute” became a thing. Mostly these days I rely on Command-Shift-/ (Menubar search), but that is a poor poor substitute. Shortcat really shines in dynamic context selection, like when trying to navigate something like Outlook for Mac, where you don’t know the shortcuts and don’t care to use them, and anyway just want to select the email that contains the text you’ve already started reading. Or things like the preference menus where navigating the combination of tabs and sidebars can be especially unclear from a keyboard perspective.
Thank you for not using electron
One issue I had with running this aside from it taking quite a lot of CPU is that when opening Discord, I'd always get a warning that I am using a screen reader.
Was it solved in new versions?
> it taking quite a lot of CPU
Yes that is fixed.
The reason for slow performance + high cpu usage on electron/webkit apps was just the sheer amount of mach ipc calls (from the many many <div> layers) needed to be made to fetch the entire UI element tree.
This has been fixed two days ago Heres the solution for those interested: https://github.com/dexterleng/vimac/pull/190
I was also using a bunch of async queues instead of just a single NSThread which likely contributed to high cpu usage, and that has also been fixed.
> warning that I am using a screen reader.
Nope, you should get this warning, although it was a one time prompt for me. This is because Accessibility is opt-in for electron apps for performance reasons, and I have to ask for it through setting the AXManualAccessibility attribute (see https://electronjs.org/docs/tutorial/accessibility#assistive...), which I guess triggers the prompt.
Why did you choose to use electron for something so specific to MacOS?
Awesome project by the way. This will save my wrists from a lot of pain.
The app is written in Swift, not Electron.
Vimac had major performance issues previously when traversing the UI Element tree of Electron/Webkit apps.
> Why did you choose to use electron for something so specific to MacOS?
I think you're mistaken. OP is referring to Discord as the webkit/electron app.
I don’t think they did. They’re just talking about the high cpu usage when trying to navigate an electron app while using vimac.
Great work! I am just trying it out, but realized it doesn't highlight links/buttons in Firefox. Is that outside the scope of this tool? If so, do you just suggest using Vimac in combination with Vimium?
It actually technically could support Firefox/chrome, but I have disabled it because enabling accessibility on chrome breaks window managers.
Also vimium will always be faster than vimac due to how slow the accessibility API is.
I would recommend using both for now.
One missing piece worth noting is Vimium doesn't seem to support navigating preferences, bookmarks, etc. in Firefox or anything in the toolbar. Not sure if that is possible solely with the WebExtensions API.
Great work @dexterlang. Thanks for building it. I am already actively using it and really like it.
I don't know vim. If I get used to this, will I be halfway to knowing vim?
Nope. This is really just making your GUI work better with the keyboard. Editing text is fundamentally different than manipulating a graphical interface, so this doesn't mimic any vim functionality (with one exception: when this app is in scroll mode, you can use HJKL keys to scroll windows contents.)
It's very much like Vimium, which is nothing like Vim, so no. I see Vimium being referred to as "vim bindings" for chrome which I never got. Maybe someone could enlighten me on this.
There are some bindings that are the same as vim (gg, G, /, i, v, etc.). But overall I wouldn't say it helps you learn vim.
well i mean vimium implements a lot of similar bindings from com.
navigation visual selection find scroll
You will be some part of the way to knowing navigation in vim.
I love this! As a colemak-dh user, is there a way to easily re-kebind hjkl?
Yes, you can do so!
Thank you!! Can’t wait to try this out.
Love this app. Absolutely check it out if you are serious about keyboard navigation.
The only suggestion I’d make is to have the cursor return to its old position after an action. But it’s a minor nitpick.
I'm glad you like it!
> cursor return to its old position after an action
Will do!
make it optional =)
The headlining quote on the site seems a bit silly. Does anyone consider their Mac trackpad to be "clunky"?
It's the best trackpad out there, and all trackpads are clunky and non-ergonomic. A mouse, keyboard, touchscreen, or almost anything else is better. Due to the location of a trackpad you are guaranteed to have your wrist bent which limits how long you can work before discomfort.
I consider trackpads in general to be 'clunky' (not as easy to use) to use relative to a mouse.
Haha, I wrote that on a whim. I'll come up with a better line.
Very handy!
My right wrist used to pain a lot because of excessive mouse usage. I had tried out various keyboard-driven apps but I didn't find any app practical enough for my needs, so I made one.
I'd like to share here my "generic" keyboard-driven navigation app for Windows:
I had similar problems years ago and switched to a trackball. No problems since. I use a Logitech with thumb moving the ball. I keep it and keyboard at waist level with monitor at eye level.
It took about a year without mouse use for my wrist to heal. Now I use a mouse but I'm very careful with posture and mouse positioning.
How long did it take to familiarize yourself with the trackball?
I didn't really try other pointing devices because I thought that they won't be as good as the mouse, plus I liked the idea of using keyboard-driven navigation software.
I have been looking for something like this for a LONG time. Impressive! My ideal state is to be able to navigate anything and everything with VIM keybindings. Including the physical world :)
I'm sure there's a way to hack this into a Tesla
Really want a way to have vi-mode input in all text inputs throughout the OS, hopefully that is a future possibility
I made this! It's not perfect but it's most of the way there in terms of Vim motions and operators, and works in any text field. It uses the Accessibility API when available, and then falls back to raw keypresses (like alt + right arrow to simulate `w`, etc).
In the fallback mode, not all motions are available, because we can't read cursor position or text field value without accessibility support.
Wow so cool! Hope to give this a go sometime soon
You may know this already but emacs keys are supported in all text input areas on Mac. Carl-a (start of text), Carl-e (end of text) Carl-k (cut Text to end of line) Carl-y (yank/paste cut text) and many more.
And the Mac kill ring is separate from the clipboard so that means you can have two things copied at once and insert them with separate keybindings. Unfortunately the kill ring only contains a single element, so has no history.
some other useful ones are C-h/C-d (backwords/forwards delete), C-o (insert line), and the main Emacs movement keys C-n, C-p, C-b, C-f. Remapping Capslock to be a second Control makes using these regularly much more natural. Karabiner is a good app for easily remapping keys on macOS.
It's possible to customize these as well, see e.g. https://www.hcs.harvard.edu/%7Ejrus/Site/cocoa-text.html, http://www.deepsky.com/~misaka/MacOSX/DefaultKeyBinding.dict.
This is the most promising project I've come across: https://github.com/glacambre/firenvim, although it only applies to the browser. The last time I tried it out it had some performance issues though.
This is great, thank you! Although, the name seems like a bit of a misnomer since there's not much in common with vim aside from the HJKL keys. It's more like EasyMotion or avy-mode.
The idea is great, but I don't think it'll be faster for me to navigate in Mac using vimac than using trackpad or mouse currently.
I think the thing which is not wonderful now is: in vim, you enter a mode, in that mode, you can do a series of navigation to get to the final destination. While in vimac, you enter a mode to do just one navigation and you're out of the mode, you have to press the key enter the mode again to do another navigation. This makes me feel not productive at all.
I’ve been thinking about implementing something like this for years - it’s great to see that someone actually went ahead and did it!
The accessibility API is one thing that I really miss since mostly leaving macOS for Linux. Most apps support it in at least a rudimentary way, and it allows for a bunch of neat tricks.
I really want a version of this for Windows as well!
Would also love a gnome/linux version.
I've been searching for this for almost a year... https://www.reddit.com/r/unixporn/comments/ers1b0/vimium_for...
I have yet to try it out:
I wonder why people are downvoting you for asking for a windows version. Is everyone a mac user here?
I am a Mac user, but now that you've mentioned this, I'll upvote the parent on general principle. While I don't think Vimac is specifically for me, it's odd little system-level utilities like this that would make it really tough for me to switch to Windows -- or Linux -- if I couldn't find equivalents.
I remember when you posted this on Reddit[0] very happy you continued to work on it. At one point I might even switch to macOS :)
0: https://reddit.com/r/vim/comments/dc95by/vimac_vimium_for_ma...
Great job! Always amazing when a single person sees a problem and engineers the hell out of it.
For everyone interested in efficient keyboard usage: You might enjoy KeyCombiner - a web app to organize, learn, and practice keyboard shortcuts.
awesome indeed. Any plans to support more Vim navigations, something like 'gg' and 'G' would be useful IMO. As well as the ability to use a custom 'ESC' mapping to leave the scroll mode.
Two letters appeared on a Safari tab, I typed them and nothing happened. Why?
Wow, seems phantastic. Love vimium in Firefox and all automation / keyboard remapping tools on the Mac (Keyboard Maestro, Alfred App, Karabiner Elements). Will definitely check this out.
I've been using Shortcat for this and Amethyst for tiling. Glad to see another project. Anyone know Windows OS equivalents?
This one seems to work similarly: https://www.blastsearch.net/
How does this compare to Shortcat? I tried Shortcat a while ago but it didn't work well for me
This is incredible! wow!
Thank you for this! It fills such a huge gap in my workflow!
Can someone please create this for Cubase, Logic, etc.
Thank you on behalf of my RSI.
yes yes yes yes yes. can’t wait to try this out. heavy vimium user
macOS 10.14 or later required. (Still on 10.11 here)
Shortcat (https://shortcatapp.com/) works on 10.10+
10.12 reporting in. Wondering how hard it would be to backport this... I'm not too familiar with ~macdev.
Still on 10.10 (due to SIP). Does this depend on a lot of newer system APIs?
One of the reasons i am on 10.14
macOS 10.13 is the last macOS supported on my one and only Macbook Air 13" Mid-2011 :(
Very cool!