Re: find-file-noselect needs save-match-data

[Stefan Monnier]

>> 2 - around code that needs to be run after string-match but before match-end

> I fail to understand this.

>> and of which we do not know that it leaves the match-data unaffected.
>> This may be unnecessary because the code may in fact preserve the
>> match-data even though you don't know it.
>> 
>> So although number 1 may be an unnecessary use of save-match-data, I find
>> it's usually useful/necessary.  Number 2 OTOH can often turn out to be
>> unnecessary.  Luckily number 2 is very rarely needed because in most cases
>> it's easier to restructure your code such that save-match-data is not needed
>> any more.

> Saving match-data is needed if the index for accessing match-data is
> known only after performing a second match operation like in

Yes, this is the number 2 I'm thinking of.

>> So I don't see current usage as problematic w.r.t efficiency.
> The info.el examples in my earlier mail seem to contradict this.

I'm not saying it can't be misused.  But using it right isn't that hard.
The info.el example should be fixed.

>> The only real problem with it is that people tend to not know/understand it
>> and are thus tempted to complain that most functions need to be wrapped in
>> save-match-data, which then leads to long discussions such as this one.
>> Maybe we should make the convention more prominent by adding it to the
>> docstring of save-match-data?

> We probably should remove bad uses of `save-match-data' from Emacs code
> in the first place.

Agreed.
As for removing most uses of save-match-data from files.el, I could agree.
I probably have argued against most of the ones I've seen added there, but
usually the other side wins because "well, it can't hurt to add it just
here".  So little by little it creeps in.


        Stefan