On Mon, Jan 26, 2009 at 10:23:19AM +0100, Jiří Paleček <jpale...@web.de> was heard to say: > On Mon, 26 Jan 2009 01:26:57 +0100, Daniel Burrows <dburr...@debian.org> > wrote: > >> On Sun, Jan 25, 2009 at 10:50:54PM +0100, Jiri Palecek >> <jpale...@web.de> was heard to say: >>> On Saturday 24 January 2009 16:48:33 Daniel Burrows wrote: >>> Moreover, I think it is very user hostile to search in the >>> description by >>> default. For example, if the user searches for "aptitude" and gets to >>> the >>> package "daptup", (s)he'll be probably very disappointed, because >>> there is no >>> easy clue to distinguish this from a failed search. If there was some >>> sort of >>> highlighting that would show what actually matched, things would have >>> been >>> much better. >> >> Maybe. Other people think it's user hostile to *not* search in the >> description by default. Personally, I think the big problem is that > > Maybe I have written it badly, I don't think the problem is what is > searched, but what is searched in conjunction with the manner of > presenting the results. Try to inspire yourself in the way Google (or > your favourite search engine) presents answers. They > > - rank matches in the title higher than matches in the body
Of course, "ranking" is not sensical using the '/' command, because it searches for the next closest occurrence of the search pattern. Which gets me to another question: what do you use the '/' command for? Personally, I generally only hit '/' when I'm looking for a particular package; if I want to find more packages, I use (l)imit instead. I wonder sometimes if perhaps '/' should just search package names literally, maybe falling back to patterns if a '?' or '~' is present. But I don't like the inconsistency that would create between '/' and 'l'. > - always show the matching part in bold, so you can easily see what has > been matched Until I spent quite a bit of time last autumn designing and implementing a complete replacement for aptitude's searching code, it just wasn't possible to extract this sort of information from it, which is why the wishlist asking for this feature hasn't been closed yet. Now there is some rudimentary support, but I haven't gotten around to trying to integrate it yet (thus turning up all the shortcomings I haven't thought of yet, meaning more work to get the design really right, rinse & repeat). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
