Re: Global match data considered harmful

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> The rule for where to place a save-match-data is:
 > >> around the code run between "looking-at" and "match-string-no-properties".
 > > *snort*  I'm with Juanma.
 > 
 > I'm not sure what that means.

Most of the code I write is (ab)usable by .emacs; so I put
save-match-data in the functions I write to protect naive callers from
having their match-data tromped on by my using of matching code.  If
somebody complains about slow I defun a foo-internal without using
save-match-data, and call that from foo.

Why?  I'm pretty sure there's at least one match-data-munching bug in
XEmacs's minibuffer code at the moment (or it might be setcdr abuse),
but I don't have time for a full audit and it's sufficiently
intermittent that I don't have a strong incentive to do that
anyway....  Missing save-match-data is about as hard to debug as
missing GCPRO.  :-(  Better to put in too many than too few.

 > > This is just so wrong, you know.  Not returning the match data, instead
 > > storing it in a global object, is arguably the worst design decision
 > > in all of Emacs.
 > 
 > Preaching to the choir, eh?
 > [ Well "the worst" I don't know: it's not like there's a shortage of
 >   global-abuse in Emacs. ]

No shortage, for sure, but this one is like attaching an 'invisible
property to a low-hanging rope in a narrow hallway.