Re: Discrepancy in definition/use of match-data?

["Stephen J. Turnbull" <stephen@xemacs.org>]

>>>>> "sjt" == Stephen J Turnbull <stephen@xemacs.org> 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.