On Thu, May 09, 2013 at 06:12:17PM +0200, Yann E. MORIN wrote: > Wang, All, > > On Thu, May 09, 2013 at 11:27:31PM +0800, Wang YanQing wrote: > > On Mon, May 06, 2013 at 11:15:31PM +0200, Yann E. MORIN wrote: > > > From: "Yann E. MORIN" <yann.morin.1998@xxxxxxx> > > > > > > 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 > > > > 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' > > > > [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 > > 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. Ok, indeed, I don't know regular expression in menuconfig before you point it out :) > > > [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'). Ok, I get your meaning. > > > [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 > > > > > [5] As fallback, sort symbols alphabetically > > This is in your first heuristic too. > > > > > This heuristic tries hard to get interesting symbols first in the list. > > 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). I hope more people will find the sorting is appropriate if Michal Marek accept it :) > 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. > > > 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. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
