Re: save-match-data woes

[Stefan Monnier]

> 
> On Fri, 22 Feb 2002 11:43:03 -0500, "Stefan Monnier" 
> <monnier+gnu/address@hidden> wrote:
> 
> > I think this is a wrong approach.  The match-data need only be saved
> > in a few particular circumstances and I'd rather handle those cases
> > in a special way.
> 
> Well, I'm not so sure about the "few particular circumstances". I think
> is bad for a function to arbitrarily change the match data and not
> saving it and not even documenting that it does modify it. That's bound
> to cause trouble somewhere far away, where perhaps the trouble won't be
> so easily connected with match data. I have no hard data, but my gut
> feeling is that you will end saving/restoring match-data in many places
> just to protect you against the relatively few functions that do not do
> that now. What if one of your elisp modules is safely using a function
> in another module and its maintainer just modifies slightly the
> implementation, using now pp-to-string where he didn't before? Probably
> you weren't saving match data because you didn't see the reason... and I
> fail to see *why* you should have any reason now. It is not you who
> changed anything.

My experience is quite different: the match data is in 99% of the cases
used right after a call to a regexp-match function, with almost no
other functions called inbetween apart from some very primitive ones.

Why this is so is because many functions do regexp-matching and thus
destroy the match-data: the match-data is just very volatile.  Another
reason why it's volatile is because any buffer modification can make
the match-data stale.

There are cases where it is important for the match-data to be preserved,
most notably in file-name-handlers (since various pieces of code rely
on the fact that the default implementation of file operations do not
do any regexp-matching).  But for most other cases, preserving the
match-data is just a waste of time and it's almost always easier to
use the match-data right after pattern-matching rather than rely on
the match-data being preserved (and still meaningful) by a function
whose behavior might be changed without your knowing.

> (Unrelated:) On the matter of ielm, is there any objection to my patch
> of a few days back that makes ielm-prompt customizable and read-only?

I don't have any, hence my non-response.


        Stefan