Andreas Lindhé [Sat, 17 Jan 2015 01:13:33 +0000 (02:13 +0100)]
Created a Swedish translation
Most of it is correct, some minor details are a bit awkward but that's
mostly because not all technical terms ("web terms") has a proper
Swedish translation.
> We don’t bother with `<link>`s since the commands are substitutes for clicking
> a visible element. (And at least in my experience, they’re not commonly used.)
> Moreover, if there’s a `<link>` with a `rel` attribute, there’s likely a
> corresponding `<a>`, too.
But that's wrong. `<link rel=prev/next>` is actually a _better_ candidate for
the previous or next page than looking for a link to them.
Simon Lydell [Sat, 17 Jan 2015 23:22:53 +0000 (00:22 +0100)]
Fix #249: Support other keyboard layouts than en-US
This uses lydell/vim-like-key-notation. The old notation is supported too, for
backwards compatibility: Old customizations still work, and continue to work if
the user downgrades.
Simon Lydell [Sat, 17 Jan 2015 16:38:06 +0000 (17:38 +0100)]
Add default shortcuts to new commands
- Toggle pin tab: gp (go pin)
- Duplicate tab: yt (yank tab, same as Vimium)
- Close tabs to the right: gx$ (like g$ (go to last tab), but with an x in it as
in "remove it!")
- Close other tabs: gxa (similar to gx$, go close tabs around the current)
Simon Lydell [Sat, 17 Jan 2015 16:19:25 +0000 (17:19 +0100)]
Fix #382: Support 'selection' clipboard
Supersedes #397. The p and P commands now use either the selection clipboard or
the global clipboard, whichever was used last or is supported by the OS. This is
a slightly breaking change since we used to only use the global clipboard, but
I've used this new behavior and it doesn't bother me. Morever, it is how
Pentadactyl works, and how the built-in `readFromClipboard()` function works.
Simon Lydell [Sat, 6 Dec 2014 22:42:32 +0000 (23:42 +0100)]
Make `require` more like Node.js
- Add support for `module.exports`.
- Add support for npm modules in `require()`. Note the following differences
with Node’s `require()` though:
- Only `require(path)` is supported, not `require.resolve()` or related
`module` properties etc.
- Absolute paths (`/foo/bar.js`) are not supported.
- Only JavaScript files may be required (not JSON files, for example). Paths
must not end with `.js`.
Moreover:
- `module.onShutdown(handler)` is used instead of
`require('unloader').unloader.add(handler)`.
- bootstrap.coffee has been cleaned up. I had a lot of help from looking at
<https://github.com/adblockplus/buildtools/blob/7a305df14bf3d26ff559f06082b87ff7cff4b3b8/bootstrap.js.tmpl>
- `extension/packages/` has been renamed to the more Node-style
`extension/lib/`.
- The huffman module has become its own repository, and is now `npm install`ed.
This change allows users to blacklist only some keys on a website.
These keys are not suppressed and the corresponding VimFx command is not executed.
Blacklist rules can now be of the form `<pattern>##<keyString1>#<keyString2>`.
Existing rules not using this syntax will continue to work.
Simon Lydell [Tue, 30 Sep 2014 19:17:04 +0000 (21:17 +0200)]
Try points one pixel into the elements from the edges
On newyorker.com, `transform: translate3d(0, 0, 0)` is applied on the
content container, to force hardware acceleration. It seems to move
everything a pixel, causing `document.elementFromPoint` to fail at the
edges of elements. This commit no longer looks exactly at the edges of
elements, but one pixel in, which seems to be a safer strategy. (The
marker is still nicely placed exactly on the edge, though.)
Example page:
http://www.newyorker.com/currency-tag/the-virtual-moleskine
Simon Lydell [Tue, 30 Sep 2014 18:51:27 +0000 (20:51 +0200)]
Improve markers for inline line-wrapped elements
If an inline line-wrapped element starts with a line break, its first
rect will have an area of almost zero. The marker used to end up on that
rect, seemingly on the line before the actual link, which was very
confusing. Now, such small areas are rounded to zero, and all
`visibleRects` that have a zero area are discarded, solving the problem.
An example can be found at the bottom of this page:
http://swrevisited.wordpress.com/esbr-facts/
Simon Lydell [Wed, 10 Sep 2014 19:01:04 +0000 (21:01 +0200)]
Improve marker placement and fix related bug
Before commit 89e1bc4 we used to recursively search the rect of an
element until it found a non-covered point; after that commit we changed
into only checking 6 simple locations of the element, for performance
reasons. However, this meant two problems:
- It was very confusing when markers ended up to the far right of
elements. Sometimes it was difficult to understand which element the
marker actually belonged to. Sometimes a tiny bit of the left side of
an element was covered (possible by a _transparent_ element!) causing
the marker to end up on the right instead, seemingly for no reason.
- Some elements are overlapped by one pixel both on the left and right
side (such as the github pagination links), causing no marker at all
to appear.
The solution is to use the best of both before the referenced commit and
after it. Now we check 3 (instead of 6) simple places: Only the 3 on the
left side. If the place is covered by another element, we try once to
the right of that element. So in total there may be 6 attempts, just as
before.
Author: Simon Lydell <simon.lydell@gmail.com>
Date: Sat Aug 2 16:01:36 2014 +0200
Improve marker generation performance
`getFirstNonCoveredPoint` used to recursively search the rect of an
element until it found a non-covered point. This works well most of the
time, but on some sites (such as prisjakt.se) it took way too much time.
Moreover, this technique required some CSS to be reset in a few special
cases, which is very costly performance-wise. It is also brittle and
makes the code unnecessarily complex.
Lastly, there was a bug in the algorithm that caused uncaught exceptions
sometimes (such as on youtube.com).
Now we use a much simpler approach instead.
`getFirstNonCoveredPoint` tries 6 different points of the element:
If all of those are covered (or are reported as covered because of one
of the CSS special cases we used to reset) then the whole element is
simply considered to be covered. This seems to work really well.
The above means that the markers can now be placed at any of the points
in the above figure.
The result is much faster, simpler and more robust.
Simon Lydell [Sun, 7 Sep 2014 17:42:20 +0000 (19:42 +0200)]
Improve coding style
- Almost all code is now wrapped at 80 chars, except a few special cases
such as the `commands = [...]` block in commands.coffee. I didn’t
bother to go through help.coffee and window-utils.coffee too much
since they need rewrites anyway.
- Consistent use of parenthesis when calling functions.
- Consistent use of single quotes over double quotes.
- Consistent spacing.
- Removed unused or unnecessary code.
- Refactored unload.coffee into unloader.coffee, which should be easier
to understand.
- Comments are now full sentences.
- This also fixes a few very minor bugs.
I’ve deliberately left out mode-hints/{hints,marker}.coffee to avoid
large merge conflicts with #330.
Simon Lydell [Sat, 16 Aug 2014 15:54:35 +0000 (17:54 +0200)]
Enhance marker frame handling
Previously the frame elements themselves were required to get a marker
in order to make markers for any elements inside the frame, which was
pretty confusing. Now all frames visible in the viewport are gone
through to add markers their elements.
Simon Lydell [Wed, 13 Aug 2014 19:38:36 +0000 (21:38 +0200)]
Fix #366: Allow autofocus when switching back to a tab
If a text input is focused and you switch to another window or tab
Firefox blurs the text input. When you switch back to the tab, Firefox
automatically focuses the text input again. Those focus events should be
allowed.
git://git.gir.st / VimFx.git / log