From: Michal Marek <mmarek@suse.cz>
To: Jean Delvare <jdelvare@suse.de>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Roland Eggner <edvx1@systemanalysen.net>,
Wang YanQing <udknight@gmail.com>
Subject: Re: [PATCH 12/14] kconfig: sort found symbols by relevance
Date: Mon, 24 Jun 2013 10:42:57 +0200 [thread overview]
Message-ID: <51C80691.9030106@suse.cz> (raw)
In-Reply-To: <1372060659.4310.41.camel@chaos.site>
On 24.6.2013 09:57, Jean Delvare wrote:
> 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@free.fr>
>>
>> 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.
PCI does sort before PCMCIA alphabetically ;). Also, the match lenght
will only be different when using regular expressions, so this rule will
not matter in the usual case.
>> [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.
When the prefix matches, then I agree that most people will expect the
matches be alphabetically sorted. Maybe only do this comparison only if
s1->so != 0, otherwise fallback to the strcmp() directly?
Thanks,
Michal
next prev parent reply other threads:[~2013-06-24 8:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 22:44 [pull request] Pull request for branch yem-kconfig-for-next Yann E. MORIN
2013-06-18 22:44 ` [PATCH 01/14] kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on Yann E. MORIN
2013-06-18 22:44 ` [PATCH 02/14] kconfig/lxdialog: Add definitions for mininimum (re)size values Yann E. MORIN
2013-06-18 22:44 ` [PATCH 03/14] kconfig/lxdialog: Use new mininimum resize definitions in conf_choice() Yann E. MORIN
2013-06-18 22:45 ` [PATCH 04/14] kconfig/lxdialog: handle newline characters in print_autowrap() Yann E. MORIN
2013-06-18 22:45 ` [PATCH 05/14] mconf: use function calls instead of ncurses' variables LINES and COLS Yann E. MORIN
2013-06-18 22:45 ` [PATCH 06/14] nconf: " Yann E. MORIN
2013-06-18 22:45 ` [PATCH 07/14] mconf/nconf: mark empty menus/menuconfigs different from non-empty ones Yann E. MORIN
2013-06-18 22:45 ` [PATCH 08/14] scripts/config: replace hard-coded script name by a dynamic value Yann E. MORIN
2013-06-18 22:45 ` [PATCH 09/14] kconfig/conf: fix randconfig setting multiple symbols in a choice Yann E. MORIN
2013-06-18 22:45 ` [PATCH 10/14] kconfig/conf: accept a base-16 seed for randconfig Yann E. MORIN
2013-06-18 22:45 ` [PATCH 11/14] kconfig/conf: print the seed used to initialise the RNG " Yann E. MORIN
2013-06-18 22:45 ` [PATCH 12/14] kconfig: sort found symbols by relevance Yann E. MORIN
2013-06-24 7:57 ` Jean Delvare
2013-06-24 8:42 ` Michal Marek [this message]
2013-06-24 17:13 ` Yann E. MORIN
2013-06-18 22:45 ` [PATCH 13/14] kconfig: loop as long as we changed some symbols in randconfig Yann E. MORIN
2013-06-18 22:45 ` [PATCH 14/14] kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG Yann E. MORIN
2013-06-19 20:40 ` [pull request] Pull request for branch yem-kconfig-for-next Michal Marek
2013-06-19 21:01 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C80691.9030106@suse.cz \
--to=mmarek@suse.cz \
--cc=edvx1@systemanalysen.net \
--cc=jdelvare@suse.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=udknight@gmail.com \
--cc=yann.morin.1998@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.