[qutebrowser] [qutebrowser/qutebrowser] Cache last fired hint for ease of access (#4373)

Jay Kamat jaygkamat at gmail.com
Mon Oct 22 05:59:05 CEST 2018

Right now, (I think) the elements are sent back to python, where they are
counted, and hints are generated based on the number of hint keys and
elements. Since we have access to the elements in python, I don't think
there's anything blocking this from happening. However, we would need to start
to store hinting history and find some algorithm for ranking things by
frequency, which wouldn't be trivial. Since the elements may not be exactly
the same, we would also need a way to treat similar elements as 'equal' as

I think there might be an issue for trying to sort hints by 'most likely to be
useful' as well.

The code for this is in qutebrowser/browser/hints.py:418 in case your curious.

Maybe adding custom mapping functions (from a list of elements to a list of
hints) could be something that is added to the plugin api. Because this seems
pretty complex, it's probably something that won't get worked on unless it's
an external contribution (or a plugin).


Christopher Geiger writes:

> Oh, what I was suggesting was a change in functionality, like instead of
> generating the hint labels sequentially, they should be generated based on
> past usage. Like you said though, this may not be feasible.
> On Sun, Oct 21, 2018, 11:15 PM Jay Kamat <jaygkamat at gmail.com> wrote:
>> Hi,
>> For some reason, your issue got deleted/dropped by github.
>> Have you seen :navigate next? It should help for this particular case.
>> I do think that :repeat-command when called on a hint should try to click
>> the
>> same link (instead of just starting hinting again), but I'm not sure how
>> feasable finding a similar hint would be.
>> Christopher Geiger writes:
>> > It would be nice if certain hint labels were preserved when moving from
>> page to page.
>> >
>> > For example, if I were navigating Github issues and I fired the hint
>> `gk` for `next page`, then on the following page, the label for the `next
>> page` hint should also be `gk`.
>> >
>> > A more involved implementation of this would be to create a priority
>> queue for frequently followed hints. For example, hints corresponding to
>> text such as `next page`, `previous page`, `go`, `search`, `run`, etc.
>> should receive easier to type labels, such as `fff` and `ggg`, as opposed
>> to sequential label generation (which might lead to frequently typed hints
>> recieving difficult to type labels).

More information about the qutebrowser mailing list