I must be missing something.
My fastri founds much less documentation than ri.
Shell output follows:
piastrella:~$ fastri-server -b
Building index.
Indexed:
* 7565 methods
* 1316 classes/modules
Needed 1.764042 seconds [...]
piastrella:~$ fri find|wc -l
3
piastrella:~$ ri find|wc -l
53
There are a couple explanations for this. From most to least important:
(1)
FastRI's search strategy is more sophisticated than ri's and it will try
several methods successively, yielding the results as soon as there's a match
(if it's unique, you get the description, otherwise a disambiguation message).
$ fri -h
Usage: fri [options] <query>
-s, --bind ADDR Bind to ADDR for incoming DRb connections.
(default: 127.0.0.1)
-O, --order ORDER Specify lookup order.
(default: eEnNpPxX)
Uppercase: case-indep.
e:exact n:nested p
artial (completion)
x:nested and partial
a:match method name anywhere
--show-matches Only show matching entries.
-S, --full-text Perform full-text search.
[...]
The default search strategy is eEnNpPxX, which means that it will try in this
order
(a) exact matches
(b) "nested matching": Foo#bar -> ActiveBar::Foo#bar & ActiveAction::Baz::Foo#bar
(c) partial matching: Foo#bar -> Foo#bar_whatever & Foo#bartender
(d) partial + nested: Foo#bar -> ActiveFoo::Foo#bartz & A::B::Foo#bart_foo
When you do fri find, since there's no exact match, by default fri will fall
back to "nested matching", yielding all methods named "find" under any
class/module:
$ fri find
------------------------------------------------------ Multiple choices:
ActiveRecord::Base.find, Daemons::Monitor.find, Enumerable#find,
Find#find, Pathname#find, Rinda::TupleBag#find, TagModule#find
By contrast, ri will return any methods matching /find/ (e.g. both
Foo#do_find_foo and Bar#find_dsad) when it doesn't find an exact match.
fri's search strategy can be specified with the -O option. You can make it
behave more like ri with -O aA:
$ fri -O aA find
------------------------------------------------------ Multiple choices:
ActionController::TestProcess#find_all_tag,
ActionController::TestProcess#find_tag,
[...]
TestAutotest#util_find_files_to_test,
TestSexp#test_find_and_replace_all, URI::Generic#find_proxy,
[...]
WSDL::XMLSchema::ComplexType#find_element_by_name,
XSD::NamedElements#find_name
$ fri -O aA find --show-matches | wc -l
95
(2) ri doesn't handle multiple versions of a gem correctly
$ ri -T ActiveRecord::Base::find
More than one method matched your request. You can refine
your search by asking for information on one of:
ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
ActiveRecord::Base::validate_find_options,
ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
ActiveRecord::Base::validate_find_options,
ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
ActiveRecord::Base::validate_find_options,
ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
ActiveRecord::Base::validate_find_options
vs.
$ fri Base.find
----------------------------------------------- ActiveRecord::Base::find
ActiveRecord::Base::find(*args)
------------------------------------------------------------------------
[...]
So there are probably many repeated entries in your ri find|wc -l
Could it be because Mac OS X has a broken installation of ruby by
default, and it's usually installed a new version in /usr/local as
[1] says? It's even suggested by Apple itself ([2]).
Maybe fastri is confused about where to look.
I believe that wasn't the case (FastRI looks for RI docs in the same dirs as
ri anyway), since:
piastrella:~$ fastri-server -b
Building index.
Indexed:
* 7565 methods
* 1316 classes/modules
You can get the full list of instance methods known to FastRI with
$ fri --show-matches "#"
Here "#" matches any instance method; in order to get all singleton
(class/module) methods, you'd do
$ fri --show-matches ::
And to get both,
$ fri --show-matches .
