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

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>     Anyway, such a function should likely _return_ the corresponding
>>     match-data (rather than setting a global variable to it), and things
>>     like match-beginning should optionally take an argument for this
>>     particular match-data.
>
>> That is a good idea.  If there is no match, it returns nil; if there
>> is a match, it returns the match data.
>
> Then what's the advantage compared to using save-match-data?

That it's reentrant...  And that it does not touch the match data.
The idea was to have a function that does not touch global data, yet
delivers the full information.

Now one problem here is that we don't want the delivery of information
to be expensive, so consing together a list is probably not really the
hottest idea.

> This whole discussion started because people want to add
> save-match-data everywhere and I pointed out that it's very rarely
> necessary, and it can be costly (where the "it" is generating the
> Lisp-level match data).  The suggestion to have a specialized
> string-match operation that preserves match-data was for performance
> reasons, AFAICT, like fast_c_string_match.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum