[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9681: Broken behaviour of re-search-backward (.+ matching only a sin
From: |
Štěpán Němec |
Subject: |
bug#9681: Broken behaviour of re-search-backward (.+ matching only a single character) |
Date: |
Fri, 7 Oct 2011 15:19:56 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
bug#9681: Broken behaviour of re-search-backward (.+ matching only a single character), Johan Bockgård, 2011/10/06