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

[Stefan Monnier]

> The main problem I currently see is that the current semantics and
> usage would want to have save-match-data used in places where actually
> nobody changes match-data.

I'm not sure I understand.
AFAIK save-match-data is only needed in 2 circumstances:

1 - when implementing a function that needs to leave the
    match-data unaffected.  This is typically only the case for functions
    that are placed on hooks.  In most cases such save-match-data are
    necessary because the function you define does touch the match-data
    (otherwise you wouldn't have used save-match-data) and the function that
    runs the hook will sooner or later need the match-data to
    stay unaffected.

2 - around code that needs to be run after string-match but before match-end
    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.

So I don't see current usage as problematic w.r.t efficiency.
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?


        Stefan