Feature request: hide/narrow down hinted links as one narrows to seach

[impaktor]

Brief description

I think I discussed this previously on IRC, with mixed reactions but, here goes:

When find-hint (or equivalent) as you type the title or url you want to go to, I'd like the hints in the buffer to also be narrowed down (see image below)

Motivation

I find this very useful, because:

• often I do not see the link I want to for all the "hinting" (think: the
  forest obscures the trees),

• and also, my mind doesn't know what index the link I want to follow has before I've issued the find-hint, so as I hit C-g, my mind already knows I can start typing "rome" to narrow down to what I want and have the screen less cluttered (it also re-indexes the links to be shorter to type).

• Once I've only have 3-4 links on screen, I can just C-n/C-p (or arrow) once or twice to get to the desired link, if my mind doesn't feel like typing the exact index.

• Another highly useful way to use this, that I use probably daily, is as a search feature. I.e. I know the url I want to is somewhere one the screen, and I know (part of) the title, but there are too many links to find it, e.g. something with "rome" in the example image, so just start typing, and I see exactly which links are of interest.

Summary

If I do narrow to search, why show non-matching link hints? They are by definition uninteresting.

Example

(from conkeror)
In this example I maybe want "Roman Greece", so I instantly start typing "rom" and instantly see the different links reagrding Rome and ancient Greece, and then just smash 4, or do 3 C-n

[chrisboeg]

I'm definitely in agreement, and I will even contribute my time to make it happen, if @jmercouris and/or @Ambrevar approves.

[Ambrevar]

Me too. After all, this is what the minibuffer is supposed to do: narrow down. The question is, because we match approximately, when precisely do we exclude candidates? After which threshold?

[chrisboeg]

@Ambrevar I think it should just match the content in the minibuffer. So as items disappear in the minibuffer as you narrow down, which they already do, their corresponding hints should disappear from the site as well, one-to-one.

[Ambrevar]

To clarify: link hints can be matched against the hint, the title, the url. Currently we support approximate matches, e.g. to match against typos. For instance if a link has the "abc" title and the user writes "acb", it should appear. This is expected. What we could do is have zero threshold on the hint match (the first word). But how do we distinguish between a hint and a title in first position? That is to say, what if there is a hint "abc" and a title "abc" or "acb"?

[chrisboeg]

So I might be confused, but I don't think that's a question for this issue. It might be relevant in general, but as I understand this issue, the problem is that if you link hint and then narrow the search, what appear in the minibuffer and as hints on the page is not one-to-one. All hints appear on the page, whereas the minibuffer shows the narrowed search matches.

So to fix the issue at hand, we should just make hints on the page one-to-one with the matches in the minibuffer.

What the matches in the minibuffer then is, like how they are filtered and determined as you mention, that's another issue.

In short: if I go to the next manual, invoke follow-hint and type "with", the minibuffer says "Go to element: [6]: with", and it shows 6 matches, but it shows 235 hints on the page. There should only be 6 hints.

At least that's how I see it.

[Ambrevar]

In short: if I go to the [next manual](https://next.atlas.engineer/documentation), invoke `follow-hint` and type "with", the minibuffer says "Go to element: [6]: with", and it shows 6 matches, but it shows 235 hints on the page. There should only be 6 hints.

OK, I had misunderstood the problem. All good then.

[chrisboeg]

@impaktor Could you shed a light on this? Is the following the problem at hand, or is there something more to it that I'm overlooking?:

if I go to the next manual, invoke follow-hint and type "with", the minibuffer says "Go to element: [6]: with", and it shows 6 matches, but it shows 235 hints on the page. There should only be 6 hints.

[impaktor]

So to fix the issue at hand, we should just make hints on the page one-to-one with the matches in the minibuffer.

Sounds like you're spot on, @chrisboeg

"Next-Manual" example

if I go to the next manual, invoke follow-hint and type "with",

EDIT so in example below, I just type "wi", and can then smash RET

[chrisboeg]

@impaktor The result you show there as number 1 in conqueror (I believe) ends up as the number 3 match in next, but that is because when you start narrowing, next also includes other things than links. I could see this be optional. However that would be another issue, another patch.

The fix for this issue would be to make the matches in the minibuffer one-to-one with the hints shown on the website.

[aartaka]

Hints on the page and hints in the minibuffer are now one, what's left is:

• Adding a prompter:filter-postprocessor filtering out non-matching hints.
• Delete the excluded hints.
• Re-draw the re-introduced ones.

Should not be terribly hard.