Stephen J. Turnbull writes:
Some time ago you reported a bug that stale match data was being
preserved. It turns out that the cases in question involved a match
that failed and returned nil.
I agree that according to existing documentation code should expect
that match data be cleared in this case, but a patch to fix the
behvaior resulted in a rash of "wrong-type-argument integerp, nil"
errors as `match-beginning' etc started returning nil instead of stale
match data. This led me to some very plausible code (cf. the function
`w3-configuration-data' in w3/w3-cfg.el) which expects the match data
to be preserved. Furthermore, this code cannot use `save-match', and
use of `match-data' and `store-match-data' would be extremely clumsy,
at best. There appears to be a fair amount of it; there are a number
of different bugs being reported that seem to be related to this
So I'm going to revert the fix at least temporarily. (The fix has not
yet been applied to 21.4; this discussion applies only to 21.5 for
Did you have a specific use for having the match data cleared? Would
you describe it?
;; return library path.
(re-search-forward "LIBDIR = \\\"\\([^ \t\n]*\\)\\\"" nil t)
(if (match-beginning 0)
(setq result (buffer-substring (match-beginning 1) (match-end 1)))))
Sometimes, re-search-forward would not find the expression. But
match-beginning still returned a true boolean value. That caused the
"if" function to execute the true block which used match data from some
previous search. Eventually it led to the ispell feature giving some
error message. It was an intermittent bug, so you will probably have
difficulty reproducing it. However, there is a fix at
ispell.el version 3.6 says:
;; return library path.
(if (re-search-forward "LIBDIR = \\\"\\([^ \t\n]*\\)\\\"" nil t)
(setq result (buffer-substring (match-beginning 1)
So the fix was to use the return value of re-search-forward rather
than the return value of match-beginning to determine if the search
Is there a practical reason why using
`(store-match-data nil)' to clear the match data would be
No. That sounds like a good technique. However, I think the technique
in ispell.el 3.6 is even more straightforward and understandable.
You mentioned that you agreed that the old behavior of xemacs is
inconsistent with the documentation. Since you are planning to use
the old behavior, I recommend changing the documentation to better
describe that behavior. Maybe the documentation should mention the
techniques of store-match-data and ispell.el 3.6.
BTW, if you keep the old behavior of match-beginning, then I recommend
that you have the xemacs project officially distribute ispell.el 3.6
since 3.6 works around the old behavior of match-beginning. BTW,
there are still other bugs in ispell.el 3.6 which are not related to
match-beginning, and I submitted fixes to ispell-el-bugs(a)itcorp.com.
But, I did not get a response, and the web site I mentioned above does
not appear to have my fixes. Let me know if you would like me to
submit my fixes to you so you can add them to the xemacs official web
(Aside from the fact that clearing the match data that
way looks to be a memory leak :-p, but I will fix that.)
Thanks for your help.
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.