bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Bastien Guerry]

`delete-char' and `delete-backward-char' modify the match data.

I know the policy is to let any function assume the match data
are not saved, but I think an exception would be useful here.

If so, I'll provide a patch.

Thanks!

-- 
 Bastien

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Stefan Monnier]

> I know the policy is to let any function assume the match data
> are not saved, but I think an exception would be useful here.

Why?


        Stefan

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I know the policy is to let any function assume the match data
>> are not saved, but I think an exception would be useful here.
>
> Why?

Because delete-char is very low-level and because it is hard to
guess why it would modify the match data -- hence very easy to
assume it will not, while it does.  Principle of least surprise?

-- 
 Bastien

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Stefan Monnier]

>>> I know the policy is to let any function assume the match data
>>> are not saved, but I think an exception would be useful here.
>> Why?
> Because delete-char is very low-level and because it is hard to
> guess why it would modify the match data -- hence very easy to
> assume it will not, while it does.

AFAIK delete-char does not modify the match-data any more than other
buffer-modifying operations (such as delete-region, insert, ...).
They all just modify the buffer, which is turn can modify the match-data
because it runs various hooks which can do all kinds of things.

> Principle of least surprise?

The rule "expect the match-data to be destroyed all the time" is the one
that leads to the least surprise.  99% of the functions can destroy the
match-data, even though they may preserve it in 99% of
the circumstances.

And in 99% of the cases where they do destroy the match-data, nobody
cares anyway, which is why we shouldn't always save-match-data.


        Stefan

bug#13260: 24.3.50; save match data for core functions like `delete-char' and`delete-backward-char'?

[Drew Adams]

> 99% of the functions can destroy the match-data, even though they
> may preserve it in 99% of the circumstances.  And in 99% of the
> cases where they do destroy the match-data, nobody cares anyway,
> which is why we shouldn't always save-match-data.

This is well put, and helpful.  How about saying something similar in the Elisp
manual?  It provides a good guideline for understanding when you might want to
save match data.

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Bastien]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAIK delete-char does not modify the match-data any more than other
> buffer-modifying operations (such as delete-region, insert, ...).
> They all just modify the buffer, which is turn can modify the match-data
> because it runs various hooks which can do all kinds of things.

Okay.

>> Principle of least surprise?
>
> The rule "expect the match-data to be destroyed all the time" is the one
> that leads to the least surprise.  99% of the functions can destroy the
> match-data, even though they may preserve it in 99% of
> the circumstances.

That's fine -- but what about "should"?  

For all the functions like (defun x () "..." (save-match-data ...))
the match data is saved.  For 99% of these functions, it's a design
choice saying "these functions *should* save the match data". (Yes,
there are such functions!)  

> And in 99% of the cases where they do destroy the match-data, nobody
> cares anyway, which is why we shouldn't always save-match-data.

I'm fine with a rule like "anything that modifies the buffer should 
be assumed to destroy the match data" -- given your explanation above.

But I'm not convinced this should apply to all other functions.

-- 
 Bastien

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> And in 99% of the cases where they do destroy the match-data, nobody
> cares anyway, which is why we shouldn't always save-match-data.

Ps: I wasn't talking about /always/ saving the match data of course.
Closing this report now.

-- 
 Bastien

bug#13260: 24.3.50; save match data for core functions like `delete-char' and `delete-backward-char'?

[Stefan Monnier]

> I'm fine with a rule like "anything that modifies the buffer should 
> be assumed to destroy the match data" -- given your explanation above.
> But I'm not convinced this should apply to all other functions.

Basically, if you need the match-data, you should get it right after the
match itself.  So save-match-data is something to use between the match
and the match-data extraction (unless this code is trivial, as is
usually the case), rather than around functions that might potentially
appear occasionally somewhere between a match and
a match-data extraction.

I know these requests will keep coming until the byte-compiler is
enhanced to flag places where a save-match-data is potentially missing,
or maybe until we replace the "string-match followed by
match-beginning/end" with a "match and then bind subgroups to provided
vars".


        Stefan