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

[martin rudalics]

> Then what's the advantage compared to using save-match-data?  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).

Yes, I proposed to add `save-match-data' to a variety of file handling
functions at the outermost level.  The main reason for my proposal was
to introduce some sort of consistency among functions in files.el with
respect to saving match-data.  If you proposed to remove _all_ instances
of `save-match-data's from files.el instead, you get my 100% agreement.
ISTR also that I was the first in this thread to mention that saving
`match-data' is expensive.  If we really cared about this we could start
right in files.el.  The following instance in `abbreviate-file-name'

                         (save-match-data
                           (string-match "^[a-zA-`]:/$" filename)))))

should be replaced by binding the outcome of (match-string 1) of the
previous string-match around it.  Though using

                         (fast-string-match "^[a-zA-`]:/$" filename))))

instead would be clearer and make such binding unnecessary ;-)

> The suggestion to have a specialized string-match operation that preserves
> match-data was for performance reasons, AFAICT, like fast_c_string_match.

It was my suggestion to introduce - on the Lisp level - somthing like
fast_string_match.  My motivation was completely different though: Code
using that function should reassure the reader that there would be no
need to save match-data around it.  It goes without saying that a "fast"
string matching function should return the same value as `string-match'
and _not_ `match-data'.

I still believe that people spend more valuable time _thinking_ about
whether match-data should be saved in a specific circumstance than when
it is actually saved on their computer.  Look at info.el: In
`Info-dir-remove-duplicates' we have

            (while (re-search-forward "^\\(\\w.*\\)\n\\*" limit t)
              (when (if re (save-match-data (string-match re (match-string 1)))
                      (equal name (match-string 1)))
                
and in `Info-fontify-node'

                        (cond ((save-match-data (looking-back "\\<see"))
                               "")
                              ((save-match-data (looking-back "\\<in"))
                               "")
                              ((memq (char-before) '(nil ?\. ?! ??))
                               "See ")
                              ((save-match-data
                                 (save-excursion
                                   (search-forward "\n\n" start t)))
                               "See ")
                              (t "see "))))

both deeply nested in loops.  Did I mention that Info's fontification
can be a pain?