-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hints mode based on typing link text (like Vimium, Vimperator and/or Pentadactyl) #340
Comments
+1 I like this idea. If the text entered uniquely identifies a link, it should be followed right away. |
In Windows alt+[(f,e,v,s,b,t,h)] will not work. It activates corresponding to letter Firefox menu. Like alt+f = File menu. Others seem to be ok |
This issue has nothing to do with the alt modifier. |
I misunderstood this then |
This feature is essential as it makes hint mode an absolute pleasure to use. There should be an option to choose between the current way hinting works, and this alternate one. Without modifiers. |
This is very similar to how Pentadactyl handled links. f would add a numerical hint to all links, and typing any characters would filter and re-number only those links which include the typed text. Very handy except when you wanted to filter by numerals. This is the main feature I miss from pentadactyl with vimium or vimfx. |
Closing because of too little interest. |
Hi, how much work would it be to add a "vimperator"-style hinting mode to vimfx? I ask, because it seems the bar to add this one feature to vimfx is probably easier than porting vimperator to e10s (vimperator is broken in the latest development builds). Ideally, I'd like to have an option to use "vimperator style (numbers, filtered by text input)"-hinting, or VimFX-hinting - set via a config-option. I'd be happy to take a stab at this, if I could be given a hint where to start? I will say, that while I (personally, not meant as s judgement on what others prefer) find the VimFX-style hinting broken, it did get a lot better with the addition of hold-shift for transparency #220 -- but it should probably be added to the help ("?") screen for new users? |
If the only thing you miss from Vimperator is this alternate hinting mode, then, yes, I guess it's easier to add that to VimFx than porting Vimperator e10s. If not, I warn you that VimFx will probably always disappoint you, since the two are different by design (otherwise VimFx wouldn't have been made in the first pace ;) ).
If you do take at stab at this, please keep the following in mind:
What do you mean by broken? Would you mind elaborating on that?
Please elaborate on this as well! :)
I agree that the use of modifiers in Hints mode is pretty hidden. Do you have a suggestion on how that would look like in the help dialog? Or do you think there's some other way? |
Thank you for the pointers, I will have to experiment a bit and see what I find out. I'm guessing the easiest/cleanest might be to write a separate matching command, as the algorithm is a bit different - updating the set of links on text input (eg: going from numbers 1-10 to 1-2, to only one match, which means follow link). So there'd need to be an array of link tuples with link-text and link, and some way to filter on substring match against the array, and a running update of the number-ids of the links. On your three points: I appreciate that this is different from how VimFX works, and I'm prepared to maintain it myself - if/when I get it working. Your offer to help with questions is much appreciated :-) As for why I prefer "vimperator-style" hinting: When reading text, switching to hinting mode, I can just "continue where I left off". So if I see a link that says comment, I can just hit f, and type "co1". (Almost) every time I want to follow a link that is labelled "comment". With VimFX style hinting, a hacker news comment link might sort as "ahl", rather than "co". Similarly, a "submit" will almost always be something like "fsub", not randomly "fxkl" on one page (many links ahead of the subit-button, and "fa" on another. So it gives some more consistency to the user experience of browsing without the mouse. This ties into the shift-hold for transparency - sometimes (this might be due to my zoom level on my high dpi screen) small links (like those awful voting-arrows on hacker news) are obscured by the (relatively) long tags that VimFX hinting generates for sites with 100s of links -- and the shift-hold makes it easier to see which link I want. Again, the ability to filter down to "reply" or "comment" - even if there are many of those makes it easier to prevent following the wrong link (say flagging a comment by mistake). This is also similar for other link-rich sites, like Facebook. As for help-text, last I checked, shift-hold for transparency wasn't mentioned in the help("?") page at all? Or maybe I just overlooked it? Finally, regarding the different design of VimFX and vimperator -- I do like many of the differences, keeping the feature set minimal. Perhaps I would ultimately be even more happy with making a friendly fork - but that would mean way too much work on maintaining the fork ;-) I do see a minor benefit in having an easy way to add plugins - for vimperator the only one I use, is a plugin for noscript, giving access to the noscript context menu via the keyboard. I would probably be happy with something similar from the ":" command console that VimFX makes available, but that is a minor issue. The main thing for me is an alternate hinting mode, that fits my work/browse-flow better. |
Thanks such a nice explanation with examples! Seems like there's definitely room for both hinting modes, depending on what people happen to prefer.
Thanks. Glad to hear that people appreciate some of the less common VimFx features!
You're right, none of the Hints mode modifiers are mentioned there. More generally, the help dialog (currently) only includes regular commands and no "special cases".
I don't know how Vimperator plugins are added, but you do know that VimFx can be quite heavily extended through a config file, right?
Here's a custom command for NoScript's context menu.
See the documentation on ex commands. |
@e12e Also, what's your time plan on this? This weekend hackathon? Couple of weeks? Months? For Christmas? Next summer? I'm fine with whatever answer; I'd just like to do some planning :) |
Btw, I’m working on adding Hints modes’s shift, ctrl and alt to the help dialog. |
@lydell: First, I'm afraid I don't have any solid timeframe to give you - so I suppose it might as well be Christmas :-/ Hopefully sooner rather than later, but until I really get started, I'm afraid I can't make any promises. Sorry about that. Second: Thank you for the documentation links. I'd browsed them before, but it's always good to be reminded. And thank you for the noscript example :) Third: Re: config.js/frame.js split: Is this due to sandboxing/permissions/namespacing? Could (should) this be hidden by allowing VimFX to split a single config.js into two temporary files on load (eg: zr -> config.js -> config.conf.js/config.frame.js)? Would it make sense to ship a :mkvimrc-ex-command that set/promted for a config-folder, created the folder if missing, and created two (or one) file with some basic examples commented out, along with a link to documentation? (Sorry to clutter up this issue with that - but it sort of belongs with your other helpful comments here). Fourth: I was wondering a bit about numbering/enumeration -- and decided to take a couple of screengrabs - this also goes along with my comments on hinting modes above. I see that vimperator and VimFX seems to number/enumerate links differently - does one of them do it in tab order[1]? Because given that many sites that care about usability sets tab-order/tabindex, it would seem that sorting links with explicit tab-ordering first, in general should lead to better UI/UX? There's been debate back and forth over the years about html document sequence of links (eg: will putting the whole menu first force a screen-reader to read a long sequence of "top", "about us", "legal" ... before getting to the first headline or not) -- and some sites will put "most important" links first. But it's not always clear if "top" or "This is the first headline" is "most important". Then there's the issue of filtering and "path length" (number of key-presses) to different links. In my first screen-shot, I show a typical hacker news page in VimFX. Note that: i) G is re-used - there's no way to get at the second "comments" link (this is probably a bug in VimFX?) ii) and iii) The most important field, the comment field, is readily available (ff), and so is the second most important link, the "add comment" button (fl). This is IMNHO good :-) iiii) However, the rather unimportant link "w" (hours ago which on hn links the comment sub-tree) is also given a "short" path (fw), while more important links like the "reply"-link "jn" is given a "longer" path (fjn). Note, I know that HN is exactly a paragon in accessibility, and I don't suggest to optimize VimFX for any one site. But contrast with the two vimperator screen-shots - one with hinting on (like the VimFX shot), the second after typing/filtering on "re". Note that "fre1" is still a "long" path - but the "re"-part is from the text, and doesn't change -- if the user knows that "reply" is the sought function -- and now it's much easier to glance at the "random" labels and find the correct link. Looking at the VimFX side, it looks like there's some work done in order to prioritize "home row" keys? Or is this particular screen-shot just an artefact of HNs deep and little odd semantic nesting (it's basically a table-based layout - hello 90s!)? Anyway, I thought the images would make things even more clear. Which brings me to the conclusion about hinting/enumerating links - should there be a strategy for making "short paths". Eg, if there's less than 26*2=56 links, which links should get the "single digit" names, etc. As mentioned I suspect there's already some kind of policy here with VimFX? [1] See eg: https://www.w3.org/WAI/UA/TS/html401/cp0101/0101-TABINDEX.htmlO |
This is due to multi-process Firefox (a.k.a. Electrolysis and e10s).
No. Too complicated.
No. Also too complicated. Config files are for advanced users. It's more important to keep VimFx small enough so that it is easy to keep working with new Firefox versions. Feel free to suggest how the documentation could be improved, though.
I don't know about Vimperator, but VimFx does not. I've never thought about it before. It might be a good idea! However, I'm not sure when I'll be in the mood of doing such an experiment with hints again. It is a tedious process that takes some time of real every-day usage to evaluate. But if you're up for it, definitely go for it! Giving the most important elements the best hints is very important. Be sure to read the documentation to learn more:
The most important thing from those links: "VimFx also tries to give you shorter hints for elements that you are more likely to click. This is done by the surprisingly simple rule: The larger the element, the shorter the hint." You might also be interested in philc/vimium#2083.
Remind me when you get that screen shot up and I'll take a look at it.
Those are large elements, so they get better hints.
That's because the current algorithm favors larger elements. The "reply" links are smaller. (And both links are
Oh yes. Have a look at https://github.com/akhodakivskiy/VimFx/blob/0bb0e8dff8824c3ed3a95a46a8d82ef45685f157/documentation/options.md#hint-chars.
Correct! It feels like I've answered this above. :)
Looking forward to it! |
Re: config - ok. (I'll ping you if I can't resist the urge to experiment with that anyway - but I understand the reasoning for why it'll probably not get included in VimFX proper. There's of course an obvious need to port vimp-plug to VimFX to manage config-snippets and ex commands ;-) ). Re: ordering/hints. Looks like there might be room for a couple of experimental feature branches, I'll focus on "vimperator style hinting" first. I suppose there's some new ground to break in keyboard-based browsing (in the sense that there aren't that many implementations that have seen actual use on the current, html5/js-rich web)- and size/visibility certainly sounds like one reasonable approach. As mentioned, I don't think optimizing for any one site is a good idea, so it might well be that what VimFX does for "vimfx hinting" is quite good enough. Note-to-self: Actually, as Firefox allows focusing elements via tab, we should probably be able to get "best" order from FF. Looks like for now it's: document order, higher tabindex-first, (eg: all tabindex=2 elements, in document order, followed by all tabindex=1 in document order, followed by other "unordered" items with tabindex=0 in order. Followed by some(?) tab-able elements in document order, but not those with tabindex=-1). Perhaps the "best" we can do for now is follow tabindex "rules": http://www.alexlande.com/articles/cross-browser-tabindex-woes/ Note-to-self II: firefox has a built-in shortcut for quick-find link text only, default bound to single-quote: '. It might be possible to leverage for "vimperator style hinting" if it's backed by an api that allows for incremental search (This is what VimFX exposes as "g/" ?).
You probably saw it, but the images should be accessible now. But given a brief reading of the links you provided, it might not be bugs after all, could simply be a case of "Another way to make hints shorter is to assign the same hint to all links with the same URL. So don’t be surprised if you see the same hint repeated several times." It's not something I feel the need to file a proper bug on for now, anyway - if it really is one, I'm sure to encounter it again on HN, and if so I'll open a (separate) issue. |
Definitely. VimFx is in no way perfect or optimal, nor will it ever be (just like all other Vimperator, Pentadactyl and Vimium won't either). Improvements are very much welcome!
Yes, that's what VimFx exposes as
Thanks to your screen shot I know get it. Yes, you're right in that it is simply a case of "Another way to make hints shorter is to assign the same hint to all links with the same URL. So don’t be surprised if you see the same hint repeated several times." Yes, you will encounter it again on HN, as well as other sites. No need to open an issue, because it is working as intended. Both of the links labeled with "G" in your screen shot do exactly the same thing, so your "there's no way to get at the second 'comments' link" statement is false. |
I'm also very interested in this - I just switched from pentadactyl and this is the one thing that still trips me up regularly that I haven't been able to either configure away or get used to. |
Work started here https://github.com/doy/VimFx/tree/pentadactyl-hints - we'll see how well it turns out(: |
Hi, I just got a new job that's likely to take much (all) of my time for the coming weeks. I'm still interested in this, but it's unlikely I'll have any time for it for at least the next few weeks. If time allows, I'll at least try to help test. Just a heads up so no one waits for my input on this. |
This brings several more or less breaking changes: - Non-hint chars now filter hint markers by the text of their elements, using an algorithm similar to the location bar (split the search term on whitespace; all the items must occur in the search text, case insensitively, and may overlap). The matched text is highlighted on screen. If all remaining hints are the same, they are automatically activated. All of this can be turned off via prefs, though. - Since space is used to filter hint markers by element text, the already existing `<space>` shortcut for rotating hint markers had to be changed. It is now `<c-space>`. (`<s-space>` remains unchanged.) - Uppercase hint chars are now allowed. This is so that people who prefer filtering by text in the first hand can use uppercase hint chars. If mixed case is used, `text-transform: uppercase;` is not applied, to avoid confusion. - Since using uppercase characters for filtering hint markers by element text and lowercase characters for hint chars (or vice versa) is now a thing, holding shift no longer lets you peek through the hint markers, because that felt like the markers blinking all the time. Instead, you now have to hold shift+control to peek through. - Hint markers are now placed immediately to left of its element's text if it would cover the text otherwise. This is because when filtering hints by text, it can be quite difficult to see what to type otherwise. This also turned out to be helpful even when only using the hints (like before). It’s nice being able to see all the link text in many cases. - Hint markers now get their `z-index` assigned based on their element's area, not their weight. It's confusing when a smaller element's hint cover the hint of a larger element. This could be the case where there are lots of small profile image links all with the same `href`. Previously, all those links got `z-index` based on their combined area. Now, their individual areas are used instead. This problem became apparent because of the above bullet point. - The hint marker(s) with the best hint are now highlighted in blue. - `<enter>` now activates the highlighted marker(s). `<c-enter>` and `<a-enter>` can be used to toggle where links open, just as when using those modifiers with the last hint char. However, these shortcuts were already taken, so the old ones had to be given new shortcuts: - "Increase count" now uses `<up>` (instead of `<enter>`). - "Toggle complementary" now uses `<c-backspace>` (instead of `<c-enter>`). - All existing hints prefs were renamed from starting with `hint_` or `hints_` to starting with `hints.`, for consistency and organization. A few new prefs starting with `hints.` were added as well. Migrations are written for this. This also unveiled a problem. If a config file tries to set an old pref and VimFx is upgraded, the config file will throw errors. This is bad user experience, so a system for allowing old names was added. However, that might mean that users never notice that they use an outdated name and never update their config files. Therefore, old names are only allowed when the config file is loaded automatically (on startup), but _not_ when it is reloaded using `gC`. The idea is that people use `gC` while working on their config file, which usually involves fixing errors. Then they could just as well fix the old pref names as well. - The options in VimFx's settings page in the Add-ons Manager have been slightly re-ordered to play better with the new options added, and to promote some very important prefs to the top. All of the above required some significant refactoring of Hints mode, that should make it more robust. Fixes #340. A big thanks to @doy who got this all started with #789.
This is now available in the development version. |
For those looking for this feature and struggle (like me) to find that it (mostly) actually works after a small settings tweak: |
There is a hint already in the description for the hint characters option.
Apart from that, it is mentioned in the Questions and Answers, which links to the documentation for hint characters which says:
|
Thanks @lydell. I read that description at least 3 times. I think it's time for a holiday. |
Edit by @lydell:
Vimium, Vimperator and Pentadactyl have hint modes mainly based on typing parts of the text of links instead of only using hints (which is the only mode VimFx has).
Do you want something like that?
https://addons.mozilla.org/en-US/firefox/addon/vimfx/reviews/596434/
The reviewer outrun suggested to introduce alternative hints mode with the following workflow:
af
- for altf
)The text was updated successfully, but these errors were encountered: