[Feature Request] DOM Link Hints
- Love this plugin
- Looking to use this instead of my website hotkey solution (on several websites I control)
Could the key-press combination be pulled from a DOM attribute if present?
<button onClick="..." vimium_keypress="np">Next Page</button>
<button onClick="..." vimium_keypress="ai">Add Item</button>
<a href="/home/tags" vimium_keypress="mt">Tags</a>
This would be in "normal" mode, not the "text-link-hint" mode.
If feasible, maybe a current contributor could implement this, or point me to the source files to look at? I have never tried modifying a complex public project like this before, but I could try....
No. I think in most situations Vimium C should avoid being affected by web pages. So it always use its own key mappings.
You may implement a independent shortcut solution in your website, and give them a same and special prefix character like /, so that users can press /np to go to next page.
So I will have to maintain my own hotkey solution, and not use Vimium C's better implementation.
The downside to Vimium C, when used in a production setting, is that the same link on the same page that is clicked 100's of times a day, Vimium C will have a different character-code-combination nearly every time since each time the page has a different number of links.
Maybe I'm the only one that finds this unnecessarily inefficient.
In the "Link Text Mode", the web page content is directly affecting Vimium C shortcuts, so the comment "Vimium C should avoid being affected by web pages" does not make sense, as it is highly affected in this case.
If Vimium C already looks at link text content, then why can't it took at a link attribute? That's not too much of a stretch.... They are both DOM elements.
LinkHints does use link text to filter hints; but the basic "key mapping" won't, so that a user can always trust Vimium C and know what a key will do at any time.
From what I could get from the documentation, each LINK is given a SCORE, and then those SCOREs are converted into character-code-combinations.
If you could point me to the source code files where the SCORE is created, and where the SCORE is used to create the character-code-combinations, that would be very helpful. I will look into a solution.
Thanks!!
Most code of LinkHints's filter text mode is in content/hint_filters.ts.
But, what do you want? If you want vimium_keypress="ai" to be used by Vimium C in normal mode to trigger a button, then I refuse it; while if you just want LinkHints's filter text mode to use attribute values like "ai", then this idea worths further discussion here.
I am looking to us this in "normal mode", which you "refuse", so I am kindly asking if you could point me to the "normal mode" source files where the "SCORE" is created and used, so I can implement my own solution.
I may not have been clear. All I am looking for is if a LINK originally had a character-combination of "SLD", then that would change to "OFL" if vimium_keypress='OFL'. All other operations remain the same.
The only complexity would be handling already-used character-combinations. This could be avoided by your suggestion of using a unique starting character like "/", but I don't know how that would effect other features.
Um, maybe we have different meanings when we said "normal mode"?
Let me ask in another way:
- do you want to press SLD to click a link without LinkHints being activated?
- or do you want to let LinkHints show a hint of SLD for the link?
vimium c's key mappings have no "score"; while LinkHints does use numbers to create hint text.
---Original--- From: @.> Date: Wed, May 31, 2023 01:16 AM To: @.>; Cc: "Dahan @.@.>; Subject: Re: [gdh1995/vimium-c] [Feature Request] DOM Link Hints (Issue #942)
I am looking to us this in "normal mode", which you "refuse", so I am kindly asking if you could point me to the "normal mode" source files where the "SCORE" is created and used, so I can implement my own solution.
I may not have been clear. All I am looking for is if a LINK originally had a character-combination of "SLD", then that would change to "OFL" if vimium_keypress='OFL'. All other operations remain the same.
The only complexity would be handling already-used character-combinations. This could be avoided by your suggestion of using a unique starting character like "/", but I don't know how that would effect other features.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Thank you for being so patient on this !! My apologies for not using the right terminology.
According to
https://github.com/gdh1995/vimium-c/wiki/Using-Link-Hints
I am referring to "Alphabet Hints" mode, where the "f" key is pressed and "characters" are shown at each link. These characters are then typed lower-case to activate the link.
It's these "characters" that are what I would like to come from a DOM attribute (vimium_linkhint='ai') if present.
Thanks!!
Um, Alphabet Hints use Characters used for link hints to decide hint strings, so it can not use DOM attribute values directly - what should LinkHint do if an attribute value has some characters in a user's Characters used for link hints and some others not in the list?
I think it may be better to make the mode of Use the link's name and characters for link-hint filtering follow DOM attributes, and then a user may type a much shorter name to locate an element. Like this snapshot:
I was thinking that the DOM attribute would be just a suggestion for the link-lint. If it uses a character not in the "Characters used for link hints" then ignore the suggestion. If there are any other issues with the suggestion, just ignore it.
Your solution would probably be the easiest since I noticed you already have a similar feature working.
I tried "Filtered Hints" mode in the extension, but found on almost every website the link-hint covers the text that I need to type to complete the hint. Making me type ESCAPE, look at and remember the text, the hit "f" to redo the link hint.
So I went back to the default "Alphabet Hints" mode, which is why I am asking if this can be implemented in "Alphabet Hints" mode.
Well, in my opinion, Filtered Hints mode is designed to work on familiar websites, and then:
- text of some buttons have been remembered
- you may still type right characters of a hinted link, like
VomnibarinHow to ... on Vomnibar - you may even type a non-unique letter to hide most mismatched hints, press
Backspacekey to reset your selection and then type what you really want
So it should have little inconvenience.
I don't like the way to change how Alphabet Hints assigns hint keys, because even if we may "ignore" non-existing characters, it still has such disadvantages:
- it will cause different key name styles for different elements. For example, some extensions may add UI panels to a page, and Vimium C can also show hints for their UI elements. Then with this feature enabled there will be two different naming styles
- it may cause longer text than expected. Now
LinkHintstries its best to find shortest key names for all hints, but your "fixed" key name may be longer than needed - For those users who has replaced
Characters used for link hintscompletely, most suggested keys will be ignored, make this feature useless for them. For example, I usedsavewrqcxz- all characters accessible from my left hand.
Ok, agreed. "Filtered Hints" is an appropriate place for this "enhancement".
By your earlier suggestion, I could use "vimium_linkhint='/np'", so if the "/" is typed first it will reduce the number of link-hints quite a bit.
I will get used to using "Filtered Hints" mode...
Tried to get used to "Filtered Hints" mode. No luck.
Averaging about 4-5 keystrokes to active a link in "Filtered Hints" mode versus 1-2 keystrokes in "Alphabet Hints" mode.
This is why I originally asked for this in "Alphabet Hints" mode.
"Filtered Hints" may be the appropriate place for this enhancement, but I would not end up using it.
Here are replies to your 3 reasons for not using "Alphabet Hints" mode:
- This enhancement is for someone wanting to enhance their own website, mostly for internal use since the number of random-website-visitors using vimium-C would be extremely minimal. They would know if any extensions caused issues and could work around them.
- Since the keys can be suggested by the DOM, yes, they might be longer than needed. But, they could be a logical value "np" = "next page".
- Again, the DOM value would be a suggestion.