On Tue, 27 Jan 2009 03:47:29 +0100, Daniel Burrows <dburr...@debian.org>
wrote:
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.
Perhaps. But then, I think it the default search should be on names only,
not to clutter the searches with unnecessary noise.
Which gets me to another question: what do you use the '/' command for?
To search for packages when I know exact name. I use regular expression
- when I don't know the exact name (eg. "curses.*perl")
- when I want to denote the beginning or end (eg. "^ht$" or "^r")
Also, I use it to execute queries like (is there a package from source
package xy instaled) "~i?source-package(xy)" [l might be more apropriate
in this case, maybe]
- 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).
That's ok.
Regards
Jiri Palecek
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
