Re: Add some aliases for re-related functions

[Stefan Monnier]

>> give you an automaton that can do the search or "RE" in O(n) time, but
>> it won't directly give you the "leftmost longest match" (instead it can
>> directly give you "the match whose match-end is closest" and "the match
>> whose match-end is furthest").
> But that's what we generally want in practice anyway.

Not according to POSIX and not according to the traditional behavior of
Emacs's regexp search.

>> Yes, it's unfortunate.  Maybe we could/should merge them to clarify:
>>      (re-match REGEXP &optional STRING LIMIT START)
>>      (re-search REGEXP &optional STRING LIMIT START)
>> would be like `looking-at` but would operate on STRING instead of
>> `current-buffer` if STRING is non-nil.  START defaults to point for
>> current-buffer and 0 for a string.
> re-search-forward also moves point, whereas string-match returns the index
> of the match start.

Oh, indeed, `re-search-forward` returns the match-end whereas
`string-match` returns the match start.  I hate that difference.

> I'm not sure it's worth the changeover and retraining everybody

Agreed.

> if the main benefit is being more aware of the underlying
> algorithm complexity.

Not sure what this has to do with the algorithm complexity.

> It suppose so. Yet, in all cases I had to rewrite looking-back calls to add
> the now-mandatory argument, the resulting time it took was fast enough to
> get lost in the measurement noise.

Yes, the limit arg hides most of the performance problems, indeed.


        Stefan