[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `looking-back' strange warning
From: |
Tassilo Horn |
Subject: |
Re: `looking-back' strange warning |
Date: |
Thu, 01 Oct 2015 11:29:36 +0200 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) |
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>>>> Docu bug?
>>>> It's a feature: calling `looking-back' without LIMIT is slow, don't do
>>>> that.
>>> Hmm, would volontier to make that fast instead - if write-permission
>>> is given :)
>> Looking at the code, I'd say `looking-back' is only slow if GREEDY is t
>> in which case the start of the match may be before LIMIT anyhow. So I
>> don't see how providing a LIMIT would help too much, or is
>> `re-search-backward' already slow without LIMIT?
>
> AFAIK thats it.
>
> Also "greedy" seems not to work at all:
>
> (defun foo3 ())
>
> (progn (re-search-backward "o+" nil t 3)
> (message "%s" (match-beginning 0)))
>
> The first "o" is reported as match-beginning.
Is it intended that you don't use `looking-back' here?
But you are right that in the situation above, a string like "foo3"
should account for only one single match because the greedy regex "o+"
is allowed to consume any number of consecutive os. But that doesn't
seem to work for backward searches, and that's probably the cause for
the weird extension mechanism in the greedy case for `looking-back'.
Well, it works fine with forward searches:
(progn (re-search-forward "fo+?" nil t) ;non-greedy
;; (re-search-forward "fo+" nil t) ;greedy
(message "%s %s" (match-beginning 0) (match-end 0)))
(defun fooooo4 ())
^ ^ ^
| | `--- end: greedy
| `------- end: non-greedy
`--------- beginning
Bye,
Tassilo
Re: `looking-back' strange warning, Andreas Röhler, 2015/10/08
Re: `looking-back' strange warning, Stefan Monnier, 2015/10/08
Re: `looking-back' strange warning, Tassilo Horn, 2015/10/08
Re: `looking-back' strange warning, Artur Malabarba, 2015/10/08
Re: `looking-back' strange warning, Tassilo Horn, 2015/10/08