If it is anything like Pentadactyl was, the difference is mainly that Vimium changes very little in Firefox. You, your spouse or your co-worker can still open Firefox and use it, as used to. Yet with pentadactyl, everything is gone: the addressbar, back-button, menu's etc. This might be what you are looking for, though.
That was one reason for me to ditch Pentadactyl (and also vimperator), and use vimium instead. It allows you to keep using Firefox as normal, gradually sliding into the habit of using the keys.
I've tried Tridactyl, Vimium, Saka Keys, Vimium C, and Vim Vixen. Of these, I found Vimium C to work the best and have the least overhead. Tridactyl added a consistent overhead of around 100 milliseconds when loading page, while Vimium and Vimum C added only about 20 ms of overhead.
In terms of features, I think Tridactyl is the most feature complete, but I found Vimium C to be more enjoyable to use. For example, Vimium C seems to produce better hints (e.g. fewer cases of hints for something you can't click on), when compared to Tridactyl. I also prefer Vimium C's "Vomnibar" over the Tridactyl interface, especially with a bit of tweaking to the theme.
FWIW - mostly for other interested readers - in Tridactyl we made hints which might be useless grey recently. They correspond to JavaScript events and are sometimes the only way to click a button.
If you want Vimium-style behaviour where these elements are not hinted you can just do `:bind f hint -J`.
We also have a Vimium-style theme which you can access with `:colours shydactyl`. The theme could do with some polishing if anyone's interested.
I’m curious about your first paragraph but I don’t understand it, can you rephrase?
DOM elements which trigger JS event on click which are not identified by shortcut tools has always annoyed me, us much that I even tried to fix it myself so I’m very interested if tridactyl has
This runs at page load - https://github.com/tridactyl/tridactyl/blob/5e8f94ff06bd5f14.... If you keep pulling that thread you'll find we use it to populate an array of elements with interesting event listeners on them. We can then put hints on those elements. We simply fire fake mouse events on those elements if they are chosen.
The code could definitely be improved - a major annoyance to me is that the JavaScript hints ignore CSS selectors.
I've been using vi-like shortcut plugins (vimperator, pentadactyl, vimium, vim vixen and many others, currently using tridactyl) for quite a few years now, and its never been quite the smooth experience I hoped for.
Not even talking about interfaces where you'd expect to need to use mouse (javascript components and others), but there is always the page in which the shortcuts will fail, or some input which will be blocked because the plugin is fighting the webpage for focus. Its pretty much what the article says at the conclusion, it helps reducing, but I still view it as a hassle.
Browsers developed with vi-like modes built-in (vimprobable, vimb, qutebrowser) fared better for me, but then there's other issues like incompatibility or lack of plugins which keeps me from fully using them.
> Browsers developed with vi-like modes built-in (vimprobable, vimb, qutebrowser) fared better for me, but then there's other issues like incompatibility or lack of plugins which keeps me from fully using them.
I've had this issue too with qutebrowser. I'm not very familiar with how these things work, but I wonder why plugins written for a given engine (say webkit) wouldn't work on all browsers using that engine. In the case of qutebrowser it uses chromium under the hood, so I would expect extensions that work on chromium to work on qutebrowser, just as most chromium limitations also apply to qutebrowser.
Extensions are tied to the browser pretty tightly (think UI, bookmarks, open tabs access, etc. etc.), while QtWebEngine (which qutebrowser uses) uses a more low-level part of Chromium which only shows a single tab (the so called "content API").
Pro tip: Set your hint characters to keys you can hit with your off-mouse hand. (e.g., being a right-handed qwerty user, mine are asdqwerzxcvtgb) Now you can keep one hand on the keyboard, the other on your mouse (or coffee, or whatever).
[Vimium + i3 + vim + vscode/vmplugin] Means that I rarely have to reach for the mouse, have a tonne of desktop real estate that's easy to navigate and is way more comfortable.
Just having search, simple navigation and the 'f-feature' in vimium is enough for like 99% of my use cases.
It's such a pleasant and seamless experience to code in the editor, hop on over to the terminal to do w/e, skip on over to the browser to look something up, and go back to code. The muscle memory just takes over. Not to mention all the other benefits like having to track down small icons, sometimes changing window state (e.g. unmaximize, moving things around), and how much more effort using a mouse is over 2-3 keystrokes.
I use the exact same setup. Although I switched to only this year after spending time revisiting my workflow. Its indeed quite a bit faster for doing serious work although when I'm just browsing casually I do use the mouse just to give my fingers a rest.
You can search for text, then press `v` to go to visual mode, and then `y` to yank.
There’s also a caret mode you can get into with `vc` that then let’s you move a caret around the page with the motion keys, and you can use it to highlight and yank text like you would in vim.
Thanks for the tip! It seems to work well. When I go to 'visual mode' its easy to move the text selector forward, but what if I want to expand back in paragraph?
Just repeating my comment here https://news.ycombinator.com/item?id=24637140 although it was Tridactyl vs QuteBrowser, the same applies. Before tridactyl, I used vimium and vim-vixen, this is the best one hands down. In terms of integration with Firefox and links recognition. For the hints, it's mainly the fact that tridactyl highlights the elements hinted, for example with the Twitter web UI:
Now it's not that a big deal, but the advantages appears clearly on more saturated pages, off the top of my head, stackoverflow's triage:
With qutebrowser[0], if I want to close the modal, `gs` and `hd` are almost on the same place (it's only with experience that I noticed that hints are top left so `hd` is the hint I'm looking for) compare this to tridactyl[1] the `hy` fits very nicely with the highlight which doesn't let any place for ambiguity. I noticed your other answer about the addons, it's very much appreciated, and if I can help with the beta or whatever, let me know, keep up with the great work.
Thanks, I ask because currently I'm using Tridactyl on Firefox but Vimium on Chrome, and it's interesting to compare the two approaches to the same problems.
I showed this once to a non-techie friend, and they were excited to use it. My little demo covered the difference between F and Shift+F to show how it is case sensitive, and I navigated through multiple pages without using a mouse. I assured them that they don't need to learn all of its commands, and they can open a cheat sheet on any page just by typing a question mark.
This non-disruptive introduction into Vimium made me think about my old Firefox setup. Back in the XUL days, I was hoarding dozens of add-ons that altered the Firefox UI to the extent that others could not use my browser anymore. They would click on a link and wonder why it is not working while my browser would amass many new tabs at a customized, designated place. The browser worked as I intended, but the extent of my customizations made it unusable for regular Firefox users.
Therefore I think that these new, more limited extension APIs offer an overall better experience for end-users. Maintaining usability for "regular users" should be the upper bound for the amount of customization an extension API provides. If it goes beyond that, it seems to get out of control.
I don't agree. Regular users simply won't know to install those plugins in the first place. Leave the advanced APIs in for those that seek it. Security and maintenance concerns aside, of course.
I love the idea of Vim shortcuts in the browser, but I'm becoming increasingly uncomfortable with the permissions these extensions require. I get why it's necessary for them to work, but giving access to all history/tabs/browser data feels a bit intense.
At least current browsers now show/ask for such permissions individually. You probably don't want to know how many permissions things like old XUL/XPCOM extensions would have required had they been forced to ask the user for them individually.
Along the same vein, I made a vi-like editor for editing webpages - not to minimize mouse usage, but to increase productivity with tons of shortcut keys and commands. https://vivpage.com/
I used vimium before switching to Surfingkeys for its editor. Turning any text input into a vim box is one of these features that you can't do without once you're used to their convenience.
Note that these extensions have access to all your data on the sites you visit, and while you may trust their developers, a dependency might go rogue without anyone noticing.
I found Surfingkeys far more configurable than Vimium. I too looked at the alternatives and think its the best of the bunch. I'll have to try those mappings, seems like good tweaks.
I love vimum, use it myself, but my biggest gripe with it (also half-addressed in the article) is that sites with good power-user focused keyboard shortcuts built-in are almost always going to beat a generic plugin like vimium. So you're left with choosing one of two compromise options:
1) Ignore the nice app-native keyboard shortcuts and just use vimium everywhere (Frustrating when single-key shortcuts in the app are multiple drop-down menu clicks with vimium)
2) Disable Vimium on shortcut-rich apps, but deal with the inconsistencies. (Eg clicking on the link in the body of an e-mail in gmail now needs a mouse again)
I really wish vimium had some kind of modifier for "send next key to website", so I could have my cake and eat it too.
Yes, exactly. It also allows you to specify keys that it should ignore per site (so that the webapp always receive them), or even completely disable vimium for a site (or just specific pages on a site). By default, it's not active on gmail for example.
I use a lot of shortcuts when browsing and when I have to switch from MacOS to Linux is always a pain in the ass because they change and is not easy to remap all of them.
Maybe trying something like this would alleviate this issue for me.
I'm glad this was posted. I really liked how they introduced only one feature; that was enough to push me to install and get past "I don't know vim, why would I like this". I can press 'f' and type letters to follow links. No vim-ness. Just a nice feature. (You can press "?" to see more features.)
(I used an XUL-based web browser with Emacs keybindings many years ago and loved it. But I had to switch to Chrome, and XUL went away, so I kind of gave up.)
> I can press 'f' and type letters to follow links.
You can get this with standard Firefox, no extension needed. For instance, on the HN main page, hit ' (single-quote) then "vi" then [enter] and you'll follow the link to this article.
I'm in love. I was able to navigate to hacker news, use F to click into the comments. Use J to read a bit, then jumped back to the top of the page and used F to highlight the text box to start typing this comment. Pair Programming is about to get a whole lot more interesting.
This is a good reminder that even engineers who think they are analytical and evidence based are subject to dogma. There has never been any study showing that not using your mouse improves coding speed. Use Vim if you want, I do, but don't state it's more efficient at writing code.
Vimium is actually quiet a stable project since it's creation in 2009.
Side note: going back on the git history of the project is a great way to see the code evolve. [1] Originally it started with 2 files, but now has blossomed into a project with 100's of files
Hm, I like this a lot. However in regard to RSI, is it more intensive to stay on the keyboard or to frequently use the mouse? Or is it the act of switch from keyboard to mouse that causes injury, and that maybe if you could do everything with the mouse, that could work to?
It’s the best extension I’ve installed. I only wish it would permit single hand navigation as a setting (e.g. left hand only with right on mouse all the time)
Does anyone know of a way to do this OS-wide, so I don’t have to use my mouse to navigate at all? Either macOS or Ubuntu/pop_os. I know most OSes have built in keyboard shortcuts, but Linux distros are often inconsistent from app to app, and besides I’m looking for something that will let me “click” anywhere in an OS without a mouse
“Keep your hands on the keyboard and boost your productivity! Shortcat is a keyboard tool for Mac OS X that lets you "click" buttons and control your apps with a few keystrokes. Think of it as Spotlight for the user interface.”
If you mean specifically a utility to have the window manager or desktop environment send mouse events to applications based on keyboard input, then no I've never heard of such a thing. It certainly might exist, but I suspect that such an approach would be full of incompatibilities. Consider that Vimium works by (among other things) parsing the DOM and making changes to it in real time. What would that look like for a desktop application with a GUI backend that's effectively a black box?
For Linux, the obvious pragmatic answer is to use a tiling window manager (i3, awm, etc) combined with terminal based programs (since they are keyboard driven by default).
Alternatively, you might have some amount of luck configuring lots of keyboard shortcuts in your window manager. You'd have to pick your programs very carefully though since most GUIs just aren't that compatible with being driven by a keyboard.
My main problem is the high cost of repeatedly switching between mouse and keyboard. Type a sentence, move to your mouse, click a link, move back to keyboard, type another sentence, move to your mouse again... It gets repetitive and tiring after a while.
I guess I don't find my typing and my mousing alternate all that much in practice? I'll try to pay more attention and see if I can better articulate this.
I do tend to use Tab to move between text entry fields...
Unusable because the vi-mode keybindings aren't available until the page finishes loading.
Qutebrowser is far superior.
Mozilla STILL refuse to produce a "libfirefox" like Chromium does with the CEF (Chromium Embedded Framework). This is incredibly selfish of Mozilla, they insist on being the only ones who can produce a browser using their browser engine, forcing Tor Browser to devote massive resources to maintaining a long-lived fork instead of just building on libfirefox.
I'm fairly sure Mozilla wished they had a libfirefox (e.g. their mobile browsers suffer from not having that), but Firefox is badly designed to make one and they didn't want to invest the resources needed to do such a deep refactoring. Maybe one can be made from the new Android FF, which as far as I understand is a more separated out code base.
110 comments
[ 0.31 ms ] story [ 686 ms ] thread[0] https://github.com/tridactyl/tridactyl
That was one reason for me to ditch Pentadactyl (and also vimperator), and use vimium instead. It allows you to keep using Firefox as normal, gradually sliding into the habit of using the keys.
In terms of features, I think Tridactyl is the most feature complete, but I found Vimium C to be more enjoyable to use. For example, Vimium C seems to produce better hints (e.g. fewer cases of hints for something you can't click on), when compared to Tridactyl. I also prefer Vimium C's "Vomnibar" over the Tridactyl interface, especially with a bit of tweaking to the theme.
If you want Vimium-style behaviour where these elements are not hinted you can just do `:bind f hint -J`.
We also have a Vimium-style theme which you can access with `:colours shydactyl`. The theme could do with some polishing if anyone's interested.
DOM elements which trigger JS event on click which are not identified by shortcut tools has always annoyed me, us much that I even tried to fix it myself so I’m very interested if tridactyl has
This runs at page load - https://github.com/tridactyl/tridactyl/blob/5e8f94ff06bd5f14.... If you keep pulling that thread you'll find we use it to populate an array of elements with interesting event listeners on them. We can then put hints on those elements. We simply fire fake mouse events on those elements if they are chosen.
The code could definitely be improved - a major annoyance to me is that the JavaScript hints ignore CSS selectors.
Not even talking about interfaces where you'd expect to need to use mouse (javascript components and others), but there is always the page in which the shortcuts will fail, or some input which will be blocked because the plugin is fighting the webpage for focus. Its pretty much what the article says at the conclusion, it helps reducing, but I still view it as a hassle.
Browsers developed with vi-like modes built-in (vimprobable, vimb, qutebrowser) fared better for me, but then there's other issues like incompatibility or lack of plugins which keeps me from fully using them.
I've had this issue too with qutebrowser. I'm not very familiar with how these things work, but I wonder why plugins written for a given engine (say webkit) wouldn't work on all browsers using that engine. In the case of qutebrowser it uses chromium under the hood, so I would expect extensions that work on chromium to work on qutebrowser, just as most chromium limitations also apply to qutebrowser.
[Vimium + i3 + vim + vscode/vmplugin] Means that I rarely have to reach for the mouse, have a tonne of desktop real estate that's easy to navigate and is way more comfortable.
Just having search, simple navigation and the 'f-feature' in vimium is enough for like 99% of my use cases.
It's such a pleasant and seamless experience to code in the editor, hop on over to the terminal to do w/e, skip on over to the browser to look something up, and go back to code. The muscle memory just takes over. Not to mention all the other benefits like having to track down small icons, sometimes changing window state (e.g. unmaximize, moving things around), and how much more effort using a mouse is over 2-3 keystrokes.
https://github.com/Zren/plasma-hud
There’s also a caret mode you can get into with `vc` that then let’s you move a caret around the page with the motion keys, and you can use it to highlight and yank text like you would in vim.
tridactyl: https://imgur.com/D1PDBgY
qutebrowser: https://imgur.com/m4vtbk0
Now it's not that a big deal, but the advantages appears clearly on more saturated pages, off the top of my head, stackoverflow's triage:
With qutebrowser[0], if I want to close the modal, `gs` and `hd` are almost on the same place (it's only with experience that I noticed that hints are top left so `hd` is the hint I'm looking for) compare this to tridactyl[1] the `hy` fits very nicely with the highlight which doesn't let any place for ambiguity. I noticed your other answer about the addons, it's very much appreciated, and if I can help with the beta or whatever, let me know, keep up with the great work.
0: https://imgur.com/H4oGufK
1: https://imgur.com/NyNyOoX
This non-disruptive introduction into Vimium made me think about my old Firefox setup. Back in the XUL days, I was hoarding dozens of add-ons that altered the Firefox UI to the extent that others could not use my browser anymore. They would click on a link and wonder why it is not working while my browser would amass many new tabs at a customized, designated place. The browser worked as I intended, but the extent of my customizations made it unusable for regular Firefox users.
Therefore I think that these new, more limited extension APIs offer an overall better experience for end-users. Maintaining usability for "regular users" should be the upper bound for the amount of customization an extension API provides. If it goes beyond that, it seems to get out of control.
Note that these extensions have access to all your data on the sites you visit, and while you may trust their developers, a dependency might go rogue without anyone noticing.
Here's my Surfingkeys configuration as an ex-Vimium user:
It makes open in new tab behave like Vimium and f work like a toggle.Hope this helps someone looking for a better option migrating from Vimium.
[0] https://github.com/brookhong/Surfingkeys
1) Ignore the nice app-native keyboard shortcuts and just use vimium everywhere (Frustrating when single-key shortcuts in the app are multiple drop-down menu clicks with vimium)
2) Disable Vimium on shortcut-rich apps, but deal with the inconsistencies. (Eg clicking on the link in the body of an e-mail in gmail now needs a mouse again)
I really wish vimium had some kind of modifier for "send next key to website", so I could have my cake and eat it too.
I thought that was what "insert mode" was used for. Hit i to go into insert mode, ESC to get out.
Tridactyl has this, bound to ctrl-v by default. Implementation is here [1] if anyone wants to try to add it to Vimium.
[1]: https://github.com/tridactyl/tridactyl/blob/5e8f94ff06bd5f14...
https://chrome.google.com/webstore/detail/ctrl-access/glmoeh...
The idea was copied from Konqueror.
I loved using Konqueror back when I used Kubuntu. It has a lot of great features that I wish were more commonly available.
Maybe trying something like this would alleviate this issue for me.
(I used an XUL-based web browser with Emacs keybindings many years ago and loved it. But I had to switch to Chrome, and XUL went away, so I kind of gave up.)
You can get this with standard Firefox, no extension needed. For instance, on the HN main page, hit ' (single-quote) then "vi" then [enter] and you'll follow the link to this article.
Together this says that you code faster by (or when?) avoiding the mouse.
Side note: going back on the git history of the project is a great way to see the code evolve. [1] Originally it started with 2 files, but now has blossomed into a project with 100's of files
[1] https://github.com/philc/vimium/commit/aff9db2640db9aa02858d...
Ever want to copy all the links in a column of a table to the clipboard? https://www.youtube.com/watch?v=PJXCnRBkHDY
Once change I'd make: Make pressing f again hide the links. So don't use f or f* as a link anywhere.
“Keep your hands on the keyboard and boost your productivity! Shortcat is a keyboard tool for Mac OS X that lets you "click" buttons and control your apps with a few keystrokes. Think of it as Spotlight for the user interface.”
https://vimacapp.com/
For Linux, the obvious pragmatic answer is to use a tiling window manager (i3, awm, etc) combined with terminal based programs (since they are keyboard driven by default).
Alternatively, you might have some amount of luck configuring lots of keyboard shortcuts in your window manager. You'd have to pick your programs very carefully though since most GUIs just aren't that compatible with being driven by a keyboard.
At least with Acme on Plan 9 I’ve found mousing to be fast, efficient, and comfortable.
I do tend to use Tab to move between text entry fields...
Qutebrowser is far superior.
Mozilla STILL refuse to produce a "libfirefox" like Chromium does with the CEF (Chromium Embedded Framework). This is incredibly selfish of Mozilla, they insist on being the only ones who can produce a browser using their browser engine, forcing Tor Browser to devote massive resources to maintaining a long-lived fork instead of just building on libfirefox.