GNU bug report logs - #31584
27.0.50; Document again what match re-search-backward finds

Previous Next

Full log

Message #20 received at 31584 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 31584 <at> debbugs.gnu.org
Subject: Re: bug#31584: 27.0.50;
 Document again what match re-search-backward finds
Date: Fri, 25 May 2018 00:47:49 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

> The docstring should definitely be clarified, but technically it can
> still be answered, if you read very carefully:
>
>     (re-search-backward REGEXP &optional BOUND NOERROR COUNT)
>
>     Search backward from point for regular expression REGEXP.
>     This function is almost identical to ‘re-search-forward’, except that
>     by default it searches backward instead of forward, and the sign of
>     COUNT also indicates exactly the opposite searching direction.
>
>     (re-search-forward REGEXP &optional BOUND NOERROR COUNT)
>
>     [...]
>     With COUNT positive/negative, the match found is [...] located
>       entirely after/before the origin of the search.

You mean the sentence about the COUNT arg?  Yes, _very_ carefully.

> It is greedy:
>
> (with-temp-buffer
>   (insert "xxxxyyyy")
>   (and (re-search-backward "x+y*" nil t)
>        (match-string 0))) ;=> "xyyyy"
>
> Non-greedy wouldn't match any "y"s.  It's a bit tricky to explain both
> correctly and clearly...

Ok, good example.  You convinced me that the sentence we once had was
actually quite good.


Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.