Re: svn: /web/php/trunk/ include/header.inc js/common.js js/jquery.autocomplete.js js/jquery.autocomplete.pack.js styles/structure.css
styles/theme.css

On 2010-12-28, at 11:04 PM, Hannes Magnusson wrote: > On Wed, Dec 29, 2010 at 02:14, Stewart Lord <stewey@ambitious.ca> wrote: > Hmh.. How did you generate the original file? > It seems to only contain functions, not methods or chapters or anything.. > Thats not intentional, is it? It's been a while, but I believe I used the same logic as quickref.php. This is what manual-lookup.php uses when there isn't an exact match. It looks like it only considers functions and classes. > When I dump the entire PhD index (including chapters and methods) I get: > 120K output/php-web/search-description.json.gz > 100K output/php-web/search-index.json.gz > > I do wonder though.. Should we try to categorize/chunk the files so we > can improve the search priority and do as we originally wanted, split > the search results into "categories". > - functions > - methods > - chapters > - references > - appendixes > - ... > That would help, especially for description matches (i.e. searching > for "audio" would give you > http://php.net/manual/en/wrappers.php.php > for example) This does sound pretty neat. Were you thinking of taking a crack at it? I wonder if it would be best left for a later pass. The scoring logic works well for matching functions, but it would need more work to match on descriptions. As an incremental improvement, we could try to add methods to the index so that searching for 'offset' would match ArrayAccess::offsetExists, offsetGet, and so on. Assuming the same structure of the index file, if you set the name of method entries to "ClassName::methodName" then the client code should just work. Also, the index file that we've been playing with has classes, but they are all lower case. It would be nice if the generated index file preserved the correct case. Stew