bug#9681: Broken behaviour of re-search-backward (.+ matching only a single character)

["Štěpán Němec" <stepnem@gmail.com>]

On Fri, Oct 07, 2011 at 09:02:18AM -0400, Stefan Monnier wrote:
> >> re-search-* stops at the first character position that has a match.
> >> And then it chooses the longest match at that position.
> > Thanks, but I'm not sure I understand what you mean here. Naturally, the
> > longest match for `re-search-backward' should be backward, not forward,
> 
> Ah, yes, sorry for being unclear: the search for a match goes backward,
> but the matching itself goes forward.
> 
> The docstring of re-search-backward is more clear about that:
> 
>    The match found is the one starting last in the buffer
>    and yet ending before the origin of the search.

I suppose that is more clear if you already know the behaviour, but I
didn't understand it that way, either. I think it should at least add
that the match is still forward, not backward, and that it might not
behave as expected for regexps containing constructs like * and +.
 
> > If I'm the only one who considers this behaviour broken (by design?[1]),
> 
> It's not the ideal behavior, admittedly.  It's even more obvious in
> `looking-back'.  But fixing it would require the implementation of
> a backward regexp matcher.

Yeah, as I said above (and as is obvious in the message quoted in the
bug report), the set of regexps usable with `re-search-backward' seems
to be quite limited, and one has to be very careful when using it (and
even some developers apparently fail at that).

So, again: it definitely needs better documentation, and IMO it also
needs fixing.

-- 
Štěpán