[Gtk-sharp-list] Re: [Mono-devel-list] A larger patch for the monodoc-browser

Lee Mallabone mono-docs at fonicmonkey.net
Wed May 21 04:48:42 EDT 2003

On Tue, 2003-05-20 at 22:23, Miguel de Icaza wrote:
> That being said, my long term plans are to use a text indexing engine
> that would index the contents, so the search is performed on that,
> rather than being performed on the captions which is not as useful.  So
> this would just be a temporary solution.
> As for the Index: I have checked in my code for creating an index, but
> it is not completed yet.  The new indexing code principle is that each
> provider would "populate" the table of contents with information that
> people would look for. 

Would I be right in thinking that this is purely the "index feature",
(as in a book index), and that work on "indexing" for the search feature
hasn't yet started? Or are you planning to reuse the same backend for
both features?

A few posts recently are all very ambiguous (without staring at a fair
bit of code) as to which indexing they mean. It appears as if all recent
indexing discussion is to do with creating the index feature, rather
than creating an indexer API for the providers to use to populate data
for the search feature.

I only ask because I have "look at indexing for the search feature" on
my mental todo list for the browser/providers. However, it's something I
don't want to spend a weekend looking at sometime if anyone else ends up
doing a chunk of searching work before I get chance...

Miguel, do you think it would be appropriate to add a line/subsection to
each item in browser/TODO with details of who, if anyone, is working on
each feature?

>   Once the data is populated, a compact index is
> written out.  Then this is used to present a list that the user can
> browser, or can be used to dynamically search the index. 

Again, I'm a little confused as to whether this means there's now an API
for providers to add data to a search index?



More information about the Mono-devel-list mailing list