Wish: exact matches displayed first

I wish a search in "make menuconfig" would return an exact match, if it exists, first in the list. At the moment, looking for "PCI", for example, returns several dozen entries (anything matching "PCI") and CONFIG_PCI is far away from the top. Ideally I would expect this query to return CONFIG_PCI first.

Quoted 5 lines · Jean Delvare

I wish a search in "make menuconfig" would return an exact match, if it exists, first in the list. At the moment, looking for "PCI", for example, returns several dozen entries (anything matching "PCI") and CONFIG_PCI is far away from the top. Ideally I would expect this query to return CONFIG_PCI first.

Indeed, this has bugged me a few times, too.
I'll see what I can do.

Quoted 7 lines · Yann E. MORIN

Quoted 5 lines · Jean Delvare

I wish a search in "make menuconfig" would return an exact match, if it exists, first in the list. At the moment, looking for "PCI", for example, returns several dozen entries (anything matching "PCI") and CONFIG_PCI is far away from the top. Ideally I would expect this query to return CONFIG_PCI first.

Quoted 2 lines

Indeed, this has bugged me a few times, too.
I'll see what I can do.

BTW, did you know that you can search using extended regular expressions? Searching for ^PCI$ will yield only the CONFIG_PCI symbol.

Quoted 2 lines · Yann E. MORIN

BTW, did you know that you can search using extended regular expressions? Searching for ^PCI$ will yield only the CONFIG_PCI symbol.

Wow, I didn't know that. Is this documented/advertised somewhere?

Thomas, All,

Quoted 4 lines · Thomas Petazzoni

Quoted 2 lines · Yann E. MORIN

BTW, did you know that you can search using extended regular expressions? Searching for ^PCI$ will yield only the CONFIG_PCI symbol.

Quoted 1 line

Wow, I didn't know that. Is this documented/advertised somewhere?

Yes. In Documentation/kbuild/kconfig.txt:

[...] This will tell you that you can also use regular expressions (regexes) in the search string, [...]

Quoted 9 lines · Yann E. MORIN

Thomas, All,

Quoted 5 lines · Thomas Petazzoni

Quoted 2 lines · Yann E. MORIN

BTW, did you know that you can search using extended regular expressions? Searching for ^PCI$ will yield only the CONFIG_PCI symbol.

Wow, I didn't know that. Is this documented/advertised somewhere?

Quoted 4 lines

Yes. In Documentation/kbuild/kconfig.txt:

[...] This will tell you that you can also use regular expressions (regexes) in the search string, [...]

Maybe this could be mentioned in the prompt itself, for all the ignorants amongst us?

Quoted 9 lines · Jean Delvare

Quoted 4 lines · Yann E. MORIN

Yes. In Documentation/kbuild/kconfig.txt:

[...] This will tell you that you can also use regular expressions (regexes) in the search string, [...]

Maybe this could be mentioned in the prompt itself, for all the ignorants amongst us?

In the search dialog, if you select 'Help', you'll get:

Search for symbols and display their relations. Regular expressions are allowed.
Example: search for "^FOO"

I guess it being presented in the help text is enough, no? ;-)

Jean, All,

Quoted 7 lines · Yann E. MORIN

Quoted 5 lines · Jean Delvare

I wish a search in "make menuconfig" would return an exact match, if it exists, first in the list. At the moment, looking for "PCI", for example, returns several dozen entries (anything matching "PCI") and CONFIG_PCI is far away from the top. Ideally I would expect this query to return CONFIG_PCI first.

Quoted 2 lines

Indeed, this has bugged me a few times, too.
I'll see what I can do.

BTW, did you know that you can search using extended regular expressions? Searching for ^PCI$ will yield only the CONFIG_PCI symbol.

Otherwise, I have a patch (that I'll submit shortly) to sort the symbols by releveance.

From: "Yann E. MORIN" <[email protected]>

When searching for symbols, return the symbols sorted by relevance.

Relevance is the ratio of the length of the matched string and the length of the symbol name. Symbols of equal relevance are sorted alphabetically.

Reported-by Jean Delvare <[email protected]>

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Jean Delvare <[email protected]>

Cc Michal Marek <[email protected]>

Cc Roland Eggner <[email protected]>

Cc Wang YanQing <[email protected]>

---
 scripts/kconfig/symbol.c | 66 +++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 57 insertions(+), 9 deletions(-)

Quoted 14 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

When searching for symbols, return the symbols sorted by relevance.

Relevance is the ratio of the length of the matched string and the length of the symbol name. Symbols of equal relevance are sorted alphabetically.

Reported-by Jean Delvare <[email protected]>

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Jean Delvare <[email protected]>

Cc Michal Marek <[email protected]>

Cc Roland Eggner <[email protected]>

Cc Wang YanQing <[email protected]>

Quoted 3 lines

---
 scripts/kconfig/symbol.c | 66 +++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 57 insertions(+), 9 deletions(-)

I did not look at the code, only tested it, and it does what I asked for
originally: exact match is listed first. So thank you :)

However I am not sure if your implementation is what we want. Your definition of "relevance" is somewhat arbitrary and may not be immediately to others. For example, my own definition of "relevance" was that symbols which start with the subject string are more relevant than the symbols which have the string in the middle. Others would possibly have other definitions.

So in the end you have somewhat complex code for a sort order which may surprise or confuse the user. It may put close to each other options which are completely unrelated, and suboptions very far from their parent.

I am wondering if it might not be better to go for a more simple
strategy: exact match on top and then sort alphabetically. Or even just sort alphabetically - now that I know regexps are supported, it is easy to get the exact match when I need it.

Thanks for your work anyway,

Quoted 7 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

When searching for symbols, return the symbols sorted by relevance.

Relevance is the ratio of the length of the matched string and the length of the symbol name. Symbols of equal relevance are sorted alphabetically.

I did not look at the code, only tested it, and it does what I asked for
originally: exact match is listed first. So thank you :)

However I am not sure if your implementation is what we want. Your definition of "relevance" is somewhat arbitrary and may not be immediately to others. For example, my own definition of "relevance" was that symbols which start with the subject string are more relevant than the symbols which have the string in the middle. Others would possibly have other definitions.

When searching for symbols, return the symbols sorted by relevance.

From: "Yann E. MORIN" <[email protected]>

When searching for symbols, return the symbols sorted by relevance.

Sorting is done as thus:

  - first, symbols with a prompt,   [1]
  - then, smallest offset,          [2]
  - then, shortest match,           [3]
  - then, highest relative match,   [4]
  - finally, alphabetical sort      [5]

So, searching (eg.) for 'P.*CI' :

[1] Symbols of interest are probably those with a prompt, as they can be changed, while symbols with no prompt are only for info. Thus:
PCIEASPM comes before PCI_ATS

[2] Symbols that match earlier in the name are to be preferred over symbols which match later. Thus:
PCI_MSI comes before WDTPCI

[3] The shortest match is (IMHO) more interesting than a longer one. Thus:
PCI comes before PCMCIA

[4] The relative match is the ratio of the length of the match against the length of the symbol. The more of a symbol name we match, the more instersting that symbol is. Thus:
PCIEAER comes before PCIEASPM

[5] As fallback, sort symbols alphabetically

This heuristic tries hard to get interesting symbols first in the list.

Quoted 11 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

When searching for symbols, return the symbols sorted by relevance.

Sorting is done as thus:

  - first, symbols with a prompt,   [1]
  - then, smallest offset,          [2]
  - then, shortest match,           [3]
  - then, highest relative match,   [4]
  - finally, alphabetical sort      [5]

Quoted 5 lines

So, searching (eg.) for 'P.*CI' :

[1] Symbols of interest are probably those with a prompt, as they can be changed, while symbols with no prompt are only for info. Thus:
PCIEASPM comes before PCI_ATS

Search the value of symbols with no prompt are useful too

Quoted 3 lines

[2] Symbols that match earlier in the name are to be preferred over symbols which match later. Thus:
PCI_MSI comes before WDTPCI

We can achieve this with ^PCI regular search

Quoted 3 lines

[3] The shortest match is (IMHO) more interesting than a longer one. Thus:
PCI comes before PCMCIA

We can achieve this with ^PCI regular search plus your previous heuristic

Quoted 4 lines

[4] The relative match is the ratio of the length of the match against the length of the symbol. The more of a symbol name we match, the more instersting that symbol is. Thus:
PCIEAER comes before PCIEASPM

This is what your first heuristic

Quoted 1 line

[5] As fallback, sort symbols alphabetically

This is in your first heuristic too.

Quoted 1 line

This heuristic tries hard to get interesting symbols first in the list.

I don't mean your this heuristic is bad, but

maybe provide mechanism to user will make guesser life easier.

Wang, All,

Quoted 12 lines · Wang YanQing

Quoted 11 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

When searching for symbols, return the symbols sorted by relevance.

Sorting is done as thus:

  - first, symbols with a prompt,   [1]
  - then, smallest offset,          [2]
  - then, shortest match,           [3]
  - then, highest relative match,   [4]
  - finally, alphabetical sort      [5]

Quoted 7 lines

Quoted 5 lines

So, searching (eg.) for 'P.*CI' :

[1] Symbols of interest are probably those with a prompt, as they can be changed, while symbols with no prompt are only for info. Thus:
PCIEASPM comes before PCI_ATS

Search the value of symbols with no prompt are useful too

My reasonning here is that often I need to toggle a symbol, but am not sure what menu it's in, so I search for it.

Sometime, I also need to search for prompt-less symbols, too, to see why a symbol I want is not visible. But that's not the most common use-case.

Also, the examples provided were with a very verbose search: 'P.*CI' which is expected to return a hell of a lot of symbols. More precise searches will yield substancially fewer symbols, so the search results will probably fit in 1 or 2 pages, not 10+ like 'P.*CI'

Quoted 4 lines

Quoted 3 lines

[2] Symbols that match earlier in the name are to be preferred over symbols which match later. Thus:
PCI_MSI comes before WDTPCI

Quoted 1 line

We can achieve this with ^PCI regular search

Yes, but I expect users do enter the begining of symbols, not a string in the middle or at the end.

Also, as Jean and Thomas have proven, not many people know that searches can be regular expressions.

Quoted 5 lines

Quoted 3 lines

[3] The shortest match is (IMHO) more interesting than a longer one. Thus:
PCI comes before PCMCIA

We can achieve this with ^PCI regular search plus your previous heuristic

This one is not about location of the match, it's about the length of the match: the shortest the match, the more interesting it is (IMHO). So we'd prefer FOO_PCI_BAR_BUZ over A_PACI_B (when searching for 'P.*CI').

Quoted 11 lines

Quoted 4 lines

[4] The relative match is the ratio of the length of the match against the length of the symbol. The more of a symbol name we match, the more instersting that symbol is. Thus:
PCIEAER comes before PCIEASPM

This is what your first heuristic

Quoted 1 line

[5] As fallback, sort symbols alphabetically

This is in your first heuristic too.

Quoted 1 line

This heuristic tries hard to get interesting symbols first in the list.

Quoted 1 line

I don't mean your this heuristic is bad, but

This heuristic is just that: a heuristic. It kicks in only if the user dit not provide an anchored regexp (ie with start- or end-of-line).

For the ten-or-so tests I did, the sorting was rather appropriate, though that's only ten-or-so tests and is not exhaustive (and probably subject to testing bias, too).

What I'm trying to achieve here is come up with a way to sort symbols for searches of *non-anchored* regexps. Anchored regexps will always provide the results they used to provide so far.

Maybe we can emphasize in the UI the fact that regexps, and especially anchored regexps, can be used.

Quoted 1 line

maybe provide mechanism to user will make guesser life easier.

Sorry, I can't make sense of this sentence. :-( Can you elaborate a bit what you meant, please?

On Thu, May 09, 2013 at 06:12:17PM +0200, Yann E. MORIN wrote:

Quoted 3 lines

For the ten-or-so tests I did, the sorting was rather appropriate, though that's only ten-or-so tests and is not exhaustive (and probably subject to testing bias, too).

I hope more people will find the sorting is appropriate if Michal Marek accept it :)

Quoted 3 lines

Quoted 1 line

maybe provide mechanism to user will make guesser life easier.

Sorry, I can't make sense of this sentence. :-( Can you elaborate a bit what you meant, please?

The mechanism means first heuristic in previous Email patch.

I though we could get this heuristic's result by composite your first heuristic in previous Email patch with regular expression, it seams like I lost something, see above.