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

[Richard Stallman <rms@gnu.org>]

    The basic global match-data structure is an array.  Maybe we should
    make save-match-data a cheap C operation.

That can't hurt.  Would someone like to write it?

					       Another possibility for an
    (incompatible) API change would be that save-match-data _clears_ the
    match-data.  That way, nested calls of save-match-data become cheap
    since the inner levels don't need to allocate anything.

This particular incompatible change would probably be a disaster,
but maybe a new C-level implementation could optimize the usual case
and get the same speedup.

    All of the proposals of when to call and when not to call
    save-match-data revolve around the problem that save-match-data is an
    expensive operation.

Any slowdown is just part of it.  It is also something you need to
remember to do.  Whether it is fast or slow, we need to set up
guidelines for when to do it.