Hi folks,
Is there a way to search backward through a string?
* (ppcre:scan "abc" "111abc1111abc11")
3 6 #() #() * (ppcre:scan "abc" "111abc1111abc11" :start 15 :end 0)
NIL
I tried just making end < start which doesn't seem to work :). I suppose what i'm looking for is the equivalent of :from-end that most cl sequence functions have.
-Shawn
On Thu, 15 Feb 2007 20:27:45 -0800, Shawn Betts sabetts@vcn.bc.ca wrote:
Is there a way to search backward through a string?
- (ppcre:scan "abc" "111abc1111abc11")
3 6 #() #()
- (ppcre:scan "abc" "111abc1111abc11" :start 15 :end 0)
NIL
I tried just making end < start which doesn't seem to work :). I suppose what i'm looking for is the equivalent of :from-end that most cl sequence functions have.
No, there's no such thing as a :FROM-END keyword argument or the equivalent, and I'm also not aware of a regex facility in another programming language which has that.
If you really need it, you could loop through the string applying SCAN until it matches with decreasing values for START, but that could be quite inefficient, of course. An alternative would be to work on (REVERSE TARGET) instead of TARGET, but you'll have to think hard how your regular expression should look like in that case - the semantics of things like "*" will certainly be different.
Cheers, Edi.
Edi Weitz edi@agharta.de writes:
No, there's no such thing as a :FROM-END keyword argument or the equivalent, and I'm also not aware of a regex facility in another programming language which has that.
Emacs does it somehow.
If you really need it, you could loop through the string applying SCAN until it matches with decreasing values for START, but that could be quite inefficient, of course. An alternative would be to work on (REVERSE TARGET) instead of TARGET, but you'll have to think hard how your regular expression should look like in that case - the semantics of things like "*" will certainly be different.
I was afaid you'd say that :). I guess I'll look closer into how emacs does it.
Thanks!
-Shawn
On Fri, 16 Feb 2007 06:19:42 -0800, Shawn Betts sabetts@vcn.bc.ca wrote:
Edi Weitz edi@agharta.de writes:
If you really need it, you could loop through the string applying SCAN until it matches with decreasing values for START, but that could be quite inefficient, of course. An alternative would be to work on (REVERSE TARGET) instead of TARGET, but you'll have to think hard how your regular expression should look like in that case - the semantics of things like "*" will certainly be different.
I was afaid you'd say that :). I guess I'll look closer into how emacs does it.
Of course, if you're really adventurous, you could look at the source code of CREATE-SCANNER-AUX in CL-PPCRE and think about efficient variants of ADVANCE-FN for searching backwards. My guess (from looking at the Emacs C code for two minutes) is that this is more or less what Emacs is doing as well.
On Fri, 16 Feb 2007 12:58:42 +0100, Edi Weitz edi@agharta.de wrote:
Of course, if you're really adventurous, you could look at the source code of CREATE-SCANNER-AUX in CL-PPCRE and think about efficient variants of ADVANCE-FN for searching backwards. My guess (from looking at the Emacs C code for two minutes) is that this is more or less what Emacs is doing as well.
I forgot: In an empty Emacs *scratch* buffer type "aaaaaaaa" (eight #\a's) and put point in the middle (after the fourth #\a). Then evaluate (using eval-expression) the following
(re-search-forward "a+")
This should give you 9 and is what one would expect - the regex engine matches the four #\a's after point.
Now put point back in the middle of the string and evaluate
(re-search-backward "a+")
That'll give you 4, i.e. the engine matches (only) the fourth #\a - a string of length one.
I think this confirms my point that Emacs somehow has to go backwards and step by step while the regular expressions themselves still "match forwards" - so to say. It also shows that scanning backwards somehow destroys the semantics of some of the regex constituent - "*" or "+" used to mean "longest possible match", but is a string of length one really the longest match?
cl-ppcre-devel@common-lisp.net
-
Edi Weitz -
Shawn Betts