[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}
                              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

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.

reply via email to

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