Hi Yann, Sorry for the late reply... Le Wednesday 19 June 2013 à 00:45 +0200, Yann E. MORIN a écrit : > 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' : Nobody would actually search for that, so that's not a particularly good example to determine whether your sort order is sane or not. > > [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 This is not necessarily true. I often look for symbols which have no prompt, and the information I am looking for is exactly "does this symbol have a prompt or is its value determined automatically"? > [2] Symbols that match earlier in the name are to be preferred over > symbols which match later. Thus: > PCI_MSI comes before WDTPCI This makes some sense, although it could have some unexpected side effects (e.g. FOO_BAR_PCI would be listed before SOMETHING_PCI_BAZBAZ, right?) > [3] The shortest match is (IMHO) more interesting than a longer one. > Thus: > PCI comes before PCMCIA This makes sense too, but I'm sure there are cases where it will be confusing too, and alphabetical order would do it in part too. > [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 an obscure sort rule and I'm sure it will add more confusion than it will help. Alphabetical order should really be good enough at this point. > > [5] As fallback, sort symbols alphabetically > > This heuristic tries hard to get interesting symbols first in the list. I know I am the one whose question triggered this work from you, but in the end the "response" seems disproportionate. Having 5 different ordering rules is a lot, and that's quite a bit of code, which while not the most complex in the world, is still far from trivial and may require maintenance work in the future. The result of the search will be read by a human. As such, the order of the results should be immediately obvious. Returning what the user is most probably looking for first in the list is not as important as making it possible for the user to search the results for what he/she is looking for, and this can only be the case if the user understands the sort order instinctively. The 5 rules you used aren't exactly that IMHO. This situation is completely different from a web search for example, where the search engine has to select the most relevant pages because listing them all is out of the question. The original order was random and that's the worse possible order, so I am all for improving it. But I think the sort order should be driven by simple and instinctive rules. This means 1 or 2 ordering rules, not 5. As I recall, my original proposal was "exact match first, then alphabetical order." 2 rules, instinctive and easy to document. > In any case, exact match can (as previously) be requested by using > start-of-line and end-of-line in the search regexp: ^PCI$ Actually this solved my original problem just fine. As a matter of fact, I stopped replying to the original thread shortly after learning this, because I kind of lost interest in the following discussion. So I think it is more important to make it clearer that regular expressions are allowed, than to come up with a brilliant sort order. I know the help page says it, but the prompt itself only asks for a "(sub)string" and it is not immediately obvious (to me at least) that regular expressions are considered substrings. BTW, if you really decide to commit your proposal despite my concerns, you will have to document the sorting rules in the help page. Thanks, -- Jean Delvare Suse L3 -- 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
