Simon Lydell [Sun, 26 Jan 2014 14:21:07 +0000 (15:21 +0100)]
Refactor follow prev/next links
- Simplified everything.
- Made it more DRY.
- Patterns can include the * and ! wildcards, just like the black list.
- Patterns must match either at the beginning or at the end of the link
text.
- Patterns don’t match in the middle of words. Works with non-English
characters too.
Simon Lydell [Tue, 28 Jan 2014 18:52:29 +0000 (19:52 +0100)]
Improve popup passthrough check performance
Commit 468ed83 sure made the popup passthrough check more robust.
However, querying for all popups (hundreds) and looping them through on
each keypress is not optimal for performance. The solution? Use the best
of both of the old and new passthrough check.
Looking back, the issue with the old event-based passthrough check was
not that passthrough sometimes wasn’t triggered. It was that passthrough
sometimes got stuck, effectively disabling the extension. So it is not
the 'popupshowing' event that is unreliable, it is the 'popuphidden'
event. So we now use the events for toggling passthrough mode, just like
before. But when `popupPassthrough == true`, we don’t trust it. Then we
loop through all popups to see if any of them actually is open. This
means that it is only when a popup (might) be open that we use the more
expensive check, which is a good tradeoff. Even then, you probably won’t
even notice a lag or anything.
Simon Lydell [Mon, 30 Dec 2013 11:02:45 +0000 (12:02 +0100)]
Make button click depend on current mode. Fix #243
Both insert mode and disabled mode use the same greyed out icon for the
toolbar button. If you're in insert mode and click the button, we used to
disable the extension as normal. However, it felt like clicking the button
did nothing, because the icon didn't change. Even if it _would_ change, it
feels more natural if the extension is _enabled_ again at that point. So
now, if you're in insert mode and click the button, we enter normal mode.
(#243)
If the current site is blacklisted, clicking the button used to disable
the extension. Well, it was already disabled, but the button icon changed
from the blacklisted icon (red) to the disabled icon (grey). Clicking
again went back to blacklisted mode. That's pretty weird. Now we open the
menu popup when clicked instead, which will show the trash can icon which
is used to un-blacklist the site. Un-blacklisting directly when clicking
the button would be to go too far, since that can potentially remove more
blacklisting rules than the user wants to. Using the popup you have a
chance to review what will be removed when un-blacklisting.
To sum up, the button clicking is more intuitive now:
- If enabled: Disable
- Otherwise: Enable (almost)
Simon Lydell [Sun, 15 Dec 2013 18:48:11 +0000 (19:48 +0100)]
Always open regular find bar, not last used
There are three find bars: The "regular" one, the "quick find" one and the
"quick find (link only)" one. Before, the VimFx `/` command opened the one
of those three that was used last. Now, the regular is always opened.
Simon Lydell [Sat, 14 Dec 2013 11:56:54 +0000 (12:56 +0100)]
Auto-focus findbar in find mode onInput
Now, if you unfocus the text input of the findbar, it will be
automatically focused again when you start typing. Before, nothing at all
happened (commands weren't run either), which felt really weird. This
reminds you that you're still in find mode, and need to press Enter or Esc
to exit from it.
Simon Lydell [Fri, 25 Oct 2013 16:48:56 +0000 (18:48 +0200)]
Fix #213: Suppress logic bug
For example, if you press 'x' to close the current tab, it will close
before keyup fires. So keyup (and perhaps keypress) will fire in another
tab. Even if that particular tab is blacklisted, we must suppress the
event, so that 'x' isn't sent to the page. The rule is simple: If the
`suppress` flag is `true`, the event should be suppressed, no matter what.
It has the highest priority.
Previously, `vim.blacklisted` checks were performed even in keypress and
keyup, which caused the suppress to be ignored.