bug#23937: 25.0.95; Search functions doc fixes/improvements

[Stephen Berman <stephen.berman@gmx.net>]

On Tue, 12 Jul 2016 16:10:28 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 23937@debbugs.gnu.org
>> Date: Tue, 12 Jul 2016 14:26:12 +0200
>> 
>>   Set point to the beginning of the occurrence found, and return point.
>>   An optional second argument bounds the search; it is a buffer position.
>>     The match found must start at or after that position.  A value of nil
>>     means search to the beginning of the accessible portion of the buffer.
>>   Optional third argument, if t, means if fail just return nil (no error).
>>     If not nil and not t, move to limit of search and return nil.
>>   Optional fourth argument COUNT, if a positive number, means to search
>>     for COUNT successive occurrences.  If COUNT is negative, search
>>     forward, instead of backward, for -COUNT occurrences.  A value of
>>     nil means the same as 1.
>>   The match found is the COUNTth to last one (or last, if COUNT is 1 or
>>     nil) in the buffer located entirely before the origin of the search.
>
> LGTM, thanks.
>
>> If you are ok with this, should I add these two lines to all
>> *search-backward and (suitably adapted) *search-forward functions?  (The
>> two lines are currently only in {re,posix}-search-backward.)
>
> It's better for all those doc strings to be consistent, yes.

Oh, dear.  I made all the changes and was ready to commit them, when I
realized that those final two lines are only valid for positive COUNT.
Spelling it out for negative COUNT seems like overkill; how about this:

   With COUNT positive, the match found is the COUNTth to last one (or
     last, if COUNT is 1 or nil) in the buffer located entirely before
     the origin of the search; correspondingly with COUNT negative.

I hope this is the last point of this issue that needs clarifying.

Steve Berman