[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Discrepancy in definition/use of match-data?
From: |
Stephen J. Turnbull |
Subject: |
Re: Discrepancy in definition/use of match-data? |
Date: |
Wed, 16 Jun 2004 16:13:20 +0900 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (chayote, linux) |
>>>>> "sjt" == Stephen J Turnbull <address@hidden> writes:
sjt> Anyway, I've implemented a last-match-succeeded flag (for
sjt> debug usage only) and check it in match_limits and
sjt> Fmatch_data (when XEmacs is configured for error-checking).
I've changed this so that Fmatch_data saves the state of that flag
with the registers, and Fstore_match_data restores it. This is bogus
if somebody uses an explicit call to match-data, but so far I've only
seen explicit use of match-data in macros like save-match-data.
Unfortunately external packages occasionally define similar macros,
making it difficult to suppress hundreds of bogus warnings from
functions that use those macros.
sjt> If we catch anything that looks relevant to GNU Emacs I'll
sjt> report it here.
OK, I have tripped this in three functions so far. All of them look
relevant to GNU Emacs.
isearch.el (isearch-repeat): both calls to match-{beginning,end}
font-lock.el (font-lock-fontify-keywords-region):
all calls to match-{beginning,end}
(font-lock-fontify-anchored-keywords):
all calls to match-{beginning,end}
The calls in isearch.el are part of logic I don't understand yet. It
looks like a zero-length match is being used to determine whether the
isearch-success flag is lying. It should be possible to fix this, but
I don't know when I'll have time to do so.
The calls in font-lock are used to fontify text. They are guarded by a
proper test for success in the case of a MATCHER which is a regexp as
far as I can tell. So I suspect that in fact a MATCHER which is a
function is being passed in, and it succeeds even though the regexp
match failed. This is probably cc-mode, and possibly emacs-lisp-mode
too.
In all cases guarding the calls to match-{beginning,end} with a test
on last-match-succeeded seems to leave behavior unchanged, except that
font-lock seems perceptibly faster for both C and Lisp. (I haven't
tried to measure that yet, though.) Again, it's unlikely I'll have
time to dig into this soon, so I'm reporting it now.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
- Re: Discrepancy in definition/use of match-data?, (continued)
- Re: Discrepancy in definition/use of match-data?, Richard Stallman, 2004/06/10
- Re: Discrepancy in definition/use of match-data?, David Kastrup, 2004/06/10
- Re: Discrepancy in definition/use of match-data?, Stephen J. Turnbull, 2004/06/11
- Re: Discrepancy in definition/use of match-data?, David Kastrup, 2004/06/11
- Re: Discrepancy in definition/use of match-data?, Stephen J. Turnbull, 2004/06/12
- Re: Discrepancy in definition/use of match-data?, David Kastrup, 2004/06/12
- Re: Discrepancy in definition/use of match-data?, Richard Stallman, 2004/06/12
- Re: Discrepancy in definition/use of match-data?, Stephen J. Turnbull, 2004/06/14
- Re: Discrepancy in definition/use of match-data?, David Kastrup, 2004/06/14
- Re: Discrepancy in definition/use of match-data?, Stephen J. Turnbull, 2004/06/14
- Re: Discrepancy in definition/use of match-data?,
Stephen J. Turnbull <=
- Re: Discrepancy in definition/use of match-data?, Richard Stallman, 2004/06/18
- Re: Discrepancy in definition/use of match-data?, Richard Stallman, 2004/06/18
- Re: Discrepancy in definition/use of match-data?, Stephen J. Turnbull, 2004/06/23
- Re: Discrepancy in definition/use of match-data?, Richard Stallman, 2004/06/11