Re: looking-back

[Stefan Monnier]

> Monnier> (if foo t nil) can be simplified to `foo', the problem is that
> Huh?

Well, yes, (if foo t nil) is equivalent to `foo' as long as you don't
care about which non-nil value is returned or if `foo' can only
return t as a non-nil value.  That's not really relevant to the problem
discussed anyway. it was just a side note.

> Monnier>      (progn
> Monnier>        (insert "hello")
> Monnier>        (looking-back "hello\\|l"))
> 
> Monnier> returns nil.  
> 
> For me, I wouldn't put an or in this because one wouldn't know which match it
> matched. I make a decision in my code depending on what it is.  Which doesn't
> help because it says REGEXP and therefore should work, I guess.  I don't know
> how to do it differently unless you write a splitter to search each "or" piece
> one at a time.

I totally understand your position: I've used such code myself, but the
problem is that it only works correctly for some regexps and no others.
Which is why I was asking what you use it for.  Maybe you only use it
to match strings rather than regexps.  Or only some particular subset
of regexps.  Maybe for those, there's something even faster than
re-search-backward.

> Monnier> Another problem is that by warning that match-data
> Monnier> will be modified, it implicitly says that other functions that don't
> Monnier> mention it probably preserve the match-data, whereas the rule is
> Monnier> rather that the match-data is usually not preserved, and especially
> Monnier> so for functions taking regexps as arguments.
> 
> I just scarfed the docs for looking-at.

Oh my god, you're right.  Well, I think we should fix looking-at as well.

> Monnier> Finally, `looking-at' is very fast because it just does a 
> regexp-match.
> Monnier> On the other hand `looking-back' is a regexp *search* which tends to 
> be
> Monnier> orders of magnitude slower and it will typically search all the way
> Monnier> to point-min when the search fails, so we want to add a `limit'
> Monnier> argument, as is done for re-search-backward.
> 
> I guess I don't see a need to compare speeds to looking-at.  Of course, that
> is built-in code and this isn't.  99% of the time this is lighting fast too.

Most of the work of looking-back is done in C as well, so that's not
the reason for the speed difference.  The reason why I find speed relevant
here is because it seems natural for people to expect looking-back
to be "just the same as looking-at except backward", so we need to
make the difference clear.

> Monnier> The real answer is to write a regexp-engine that matches backward.
> Well, this original method works pretty swell most all the time...

It works great when it works.  But since we put it in subr.el, people
will expect it to work without ifs and whens.


        Stefan