Re: example queries for nnir

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

Harry Putnam <reader@newsguy.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > This depends on the format file.  In a `region...end' stanza, the BOTH
> > keyword means that the words are index both in the given field and in
> > the global field.  If you put LOCAL there, the words are only put into
> > the given field, and not in the global field.
> 
> Unless there is the possibility of a `body' field, how can the above
> allow a body only search?

If you specify the empty line, ie /^$/ as the beginning regexp, and
for the end regexp you either use something which never matches (for
nnml) or the record separator (/^From /, for nnfolder or mbox files),
then you have defined a region which comprises the body of a message.

Once you have such a region, you can either put all the words in it
into the global field, or into some other field.  In both cases, if
you want to be able to restrict the search to the body, you should NOT
specify another region which puts the words into the global field, or
into the other field.

My suggestion meant that you put all the words from the body into the
global field, and no other words into the global field.  Hence
searching the global field is the same as searching the body.

> > Are you saying that (setq nnir-search-engine 'wais) and (setq
> > nnir-search-engine 'imap) is not sufficient and that I should include
> > the full list of allowed symbols?
> 
> Very sorry Kai, but I thought we were discussing the opening
> comments in nnir.el.  Which should probably include the examples you
> refer to above. Those that appear in that actual code as documnet
> strings.  I had not noticed those examples which probably means many
> new users would not either.

Hm.  Okay.  I have tried to explicitly include a pointer to the
docstrings in the opening comments, but apparently this was not
explicit enough.  Do you think a wording along the lines of `type C-h
v nnir-search-engine RET for more information' would be clear enough?

If I were to document the same thing in the opening comments and in
the doc strings, chances are that one of them will be obsolete after
the next nnir.el changes.  Therefore, I prefer not to document the
same thing twice.

Do you think it would be better to document it twice?  What about the
newly changed wording in the opening comments?

> I think this is a good practice and was only suggesting that any of
> the variables discussed in comments should also have any defaults
> pointed out.

Okay.  FWIW, I have tried to make the variable documentation more
explicit, too.

> I don't see that in the opening comments.  The variable documentation
> is superb now.  I may be all wet thinking these examplse should also
> appear there but it seems to follow if it makes sense to have the
> discussion in the opening comments.  Not a big issue I guess.

I have already said why I think it's better not to document the same
thing twice...

kai
-- 
I like BOTH kinds of music.