Vimium: Is there a plugin system planned for Vimium?

[wildeyes]

I thought about integrating FastPick (webstore link) since it fits more into the spirit of Vimium rather than being a standalone extension (and the fact it didn't really pick up), but then I read CONTRIBUTING.md and it does change the 'regular` look and feel of search pages in chrome, and therefore isn't so suitable (right?, tell me if I'm wrong :)

Maybe FastPick can be integrated as plugin, so is there a system for this planned or anything like it?
(A search through the issues yielded 2 issues really unrelated to what I am thinking, so that's why I submitted this issue)

[smblott-github]

I tried Fastpick. Works nicely.

A plugin framework might be quite difficult to achieve. We'd have to provide hooks into so many different parts of the Vimium runtime.

However, we could look at your question a different way. Fastpick is based on the idea that some sites are special, sufficiently special to warrant site-specific key bindings. They bring a huge UX win on those sites. They make the user feel super awesome! (They felt awesome before, just because they're using Vimium.)

I use another extension which does the same thing (although differently). It provides j/k bindings for certain search sites (to move between results), certain news sites (to move between stories) and vbulletin sites (to move between threads or posts). It also uses Enter to follow the selected link. I feel super awesome too! And everybody else's browser feels like something from the stone age.

Currently, Vimium is (almost) site neutral. What we _could_ think about, is whether there is a way to bring the site-specific structure of Fastpick together with Vimium. For example, j/k could navigate not pixel-wise, but between logical things (search results, say). Alternatively, we could have a link-hint mode which only chooses certain elements, and assigns hints in a predictable way.

What might make that difficult is developing and maintaining a database of rules for picking the important things on sites. What's your experience with that, @wildeyes? Also, inevitably some users would want to enable or disable sites, and it's not obvious how you could do that elegantly with a (probably large) database of rules. Also, users would want to add their own rules for the sites they use most. It could get too complicated.

TL;DR. Should we consider logical hints or movements for special sites? However, can we come up with a good UX and manageable configuration system?

[mrmr1993]

A plugin framework might be quite difficult to achieve. We'd have to provide hooks into so many different parts of the Vimium runtime.

I had some ideas about how a simple plugin architecture could look over in #1392. That avoids this complexity by only providing an API to register commands (with code that's otherwise orthogonal to Vimium's), to which the user can bind keys as they see fit. To my mind, it's also very simple to implement.

With per-url mappings (#1188), this would make it easy for another extension to implement a scrollUpByItem/scrollDownByItem command, which users could map instead of (or as well as) normal scrolling for sites where they want it.

[houshuang]

I love this extensions, and actually came here to suggest something similar. Currently when using Hacker News (which I use far too often), there are far too many links on any given page. Realistically, I want to either open a story, or its comments, or very often both. Having some site-specific config that at least reserved single-letter commands to opening stories, and perhaps shift+cmd to open comment, or ctrl+cmd to open both story and comment in two tabs, would be awesome (more productive procrastination! eh)...

[nadrane]

I'm in the exact same boat as houshuang. As it stands, if we're going to be perfectly honest, the "f" key binding is overwhelming. A customizable system that pruned the number of clickable links to a half or a third of the current set would be fantastic.

[Aleroniponi]

I would love to help out with the implementation! I need practice with JS anyways.

[cpriest]

I maintain a project SnapLinks Plus (mostly for FF, the chrome extension is not at all up to date).

The method I use for link lassoing is the font-weight of the element in question, it works remarkably well.

[tylercal]

Interesting idea, @cpriest. I notice SnapLinks is using getComputedStyle with a cache. I assume the cache only helps with subsequent calls on the page?

I have a PR (https://github.com/philc/vimium/pull/2410) which also uses getComputedStyle, but I'm looking for a way to improve the performance since getComputedStyle is relatively slow.

[cpriest]

It's not terribly bad but is worth caching for a short period of time, in SLP's case it's just during the drag event as computed as needed. In the case of this feature, it would just be all links, you could get the computed style for several hundred elements in under 50ms in Firefox without any problem.

[smblott-github]

Vimium currently calculates the bounding rectangle for every element (when you hit f) in the document. It's already too slow (but faster than the alternative). Adding another expensive operation into that calculation isn't really a starter.

(The calculation is here.)