[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible problem with looking-back function

From: Andreas Röhler
Subject: Re: Possible problem with looking-back function
Date: Thu, 19 Aug 2010 11:32:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20100711 Thunderbird/3.0.6

Am 19.08.2010 11:02, schrieb Stephen J. Turnbull:
Andreas Röhler writes:

  >  that surprises me.  Check must be done against the string already
  >  found.  So workload should grow lineary resp. slightly ascending.

That's incorrect.  In regexp matching abstractly defined, there is no
"string already matched."  In general backtracking must be done to get
a correct POSIX match, and it's potentially very expensive.  It would
be sometimes possible (as in this case) to identify a non-backtracking
algorithm as you suggest, but that would mean that different regexps
would be treated differently, or that some regexps would be
ridiculously expensive.


just for the curious:
Coming upon the matter, as in markup languages point may be inside the start tag.
Solved it whith function below

--begstr is the startup-tag
Sometimes begstr is used inside beg-end function quoted: (regexp-quote begstr), therefor the startup tag is delivered in both forms here, making looking-at working
- not sure, if its really necessary btw--

(defun ar-leave-begstr-backward (begstr unquoted-beg)
  (let* ((stringcount (length unquoted-beg))
         (collected (char-to-string (char-after)))
         (indx (string-match (regexp-quote collected) unquoted-beg)))
(while (and indx (not (ignore-errors (looking-at begstr)))(< 1 stringcount))
      (forward-char -1)
      (setq collected (concat (char-to-string (char-after)) collected))
      (setq indx (string-match (regexp-quote collected) unquoted-beg))
      (setq stringcount (1- stringcount)))))

See beg-end.el



reply via email to

[Prev in Thread] Current Thread [Next in Thread]