Contributing to Vimium
You'd like to fix a bug or implement a feature? Great! Check out the bugs on our issues tracker, or implement one of the suggestions there that have been tagged "help wanted". If you have a suggestion of your own, start a discussion on the issues tracker or on the mailing list. If it mirrors a similar feature in another browser or in Vim itself, let us know. Once you've picked something to work on, add a comment to the respective issue so others don't duplicate your effort.
Please include the following when reporting an issue:
- Chrome/Chromium and OS Version:
- Vimium Version:
- Firefox and OS Version:
- Vimium Version:
about:addons, then click on
Installing From Source
- Install Coffeescript.
- Navigate to
- Toggle into Developer Mode
- Click on "Load Unpacked Extension..."
- Select the Vimium directory.
cake autobuildto watch for changes to coffee files, and have the .js files automatically regenerated
Running the tests
git submodule update --init --recursive-- this pulls in shoulda.js.
- Install PhantomJS.
npm install email@example.com install the Node.js Path module, used by the test runner.
npm install utilto install the util module, used by the tests.
cake buildto compile
cake testto run the tests.
You can find out which portions of code need them by looking at our coverage reports. To generate these reports:
- Download JSCoverage or
brew install jscoverage
npm install temp
cake coveragewill generate a coverage report in the form of a JSON file (
jscoverage.json), which can then be viewed using jscoverage-report. See jscoverage-report's README for more details.
We follow the recommendations from this style guide.
We follow two major differences from this style guide:
- Wrap lines at 110 characters instead of 80.
- Use double-quoted strings by default.
When writing comments, uppercase the first letter of your sentence, and put a period at the end.
If you have a short conditional, feel free to put it on one line:
# No if i < 10 return # Yes return if i < 10
When you're done with your changes, send us a pull request on Github. Feel free to include a change to the CREDITS file with your patch.
Vimium design goals
When improving Vimium it's helpful to know what design goals we're optimizing for.
The core goal is to make it easy to navigate the web using just the keyboard. When people first start using Vimium, it provides an incredibly powerful workflow improvement and it makes them feel awesome. And it turns out that Vimium is applicable to a huge, broad population of people, not just users of Vim, which is great.
A secondary goal is to make Vimium approachable, or in other words, to minimize the barriers which will prevent a new user from feeling awesome. Many of Vimium's users haven't used Vim before (about 1 in 5 app store reviews say this), and most people have strong web browsing habits forged from years of browsing that they rely on. Given that, it's a great experience when Vimium feels like a natural addition to Chrome which augments but doesn't break their current browsing habits.
In some ways, making software approachable is even harder than just enabling the core use case. But in this area, Vimium really shines. It's approachable today because:
- It's simple to understand (even if you're not very familiar with Vim). The Vimium video shows you all you need to know to start using Vimium and feel awesome.
- The core feature set works in almost all cases on all sites, so Vimium feels reliable.
- Requires no configuration or doc-reading before it's useful. Just watch the video or hit
- Doesn't drastically change the way Chrome looks or behaves. You can transition into using Vimium piecemeal; you don't need to jump in whole-hog from the start.
- The core feature set isn't overwhelming. This is easy to degrade as we evolve Vimium, so it requires active effort to maintain this feel.
- Developers find the code is relatively simple and easy to jump into, so we have an active dev community.
What makes for a good feature request/contribution to Vimium?
- Useful for lots of Vimium users
- Require no/little documentation
- Useful without configuration
- Intuitive or leverage strong convention from Vim
- Work robustly on most/all sites
- Are very niche, and so aren't useful for many Vimium users
- Require explanation
- Require configuration before it becomes useful
- Unintuitive, or they don't leverage a strong convention from Vim
- Might be flaky and don't work in many cases
We use these guidelines, in addition to the code complexity, when deciding whether to merge in a pull request.
If you're worried that a feature you plan to build won't be a good fit for core Vimium, just open a github issue for discussion or send an email to the Vimium mailing list.