(require 'cus-load) clobbers match-data

(require 'cus-load) clobbers match-data

[Geoff Gole]

While trying to puzzle out bug 5533
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5533>, I've found that
(require 'cus-load) will stomp on match data if the file is not
already loaded:

  emacs -Q
  (let ((md (match-data)))
    (require 'cus-load)
    (equal md (match-data)))
  => t

This is what causes the bug, but I can't figure out why it is
happening. cus-load.el is just a big list of (put ...) forms. Why is
it stomping on the match data?

Anyway, if anybody knows how to stop it doing that, that would fix bug
5533. Maybe require should save and restore the match data itself?

Re: (require 'cus-load) clobbers match-data

[David Kastrup]

Geoff Gole <geoffgole@gmail.com> writes:

> While trying to puzzle out bug 5533
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5533>, I've found that
> (require 'cus-load) will stomp on match data if the file is not
> already loaded:
>
>   emacs -Q
>   (let ((md (match-data)))
>     (require 'cus-load)
>     (equal md (match-data)))
>   => t
>
> This is what causes the bug, but I can't figure out why it is
> happening. cus-load.el is just a big list of (put ...) forms. Why is
> it stomping on the match data?
>
> Anyway, if anybody knows how to stop it doing that, that would fix bug
> 5533. Maybe require should save and restore the match data itself?

Maybe.  Things like hack-local-variables and similar affect match data.
Everything that can autoload in some manner should save match data, I
guess.

-- 
David Kastrup

Re: (require 'cus-load) clobbers match-data

[Geoff Gole]

Of course by => t, I meant => nil. Cough.

> Everything that can autoload in some manner should save match data, I
guess.

That means a lot of code is going to be subtly wrong. Wouldn't it be
easier to just have load/require do it?

Re: (require 'cus-load) clobbers match-data

[David Kastrup]

Geoff Gole <geoffgole@gmail.com> writes:

> Of course by => t, I meant => nil. Cough.
>
>> Everything that can autoload in some manner should save match data, I
>> guess.
>
> That means a lot of code is going to be subtly wrong. Wouldn't it be
> easier to just have load/require do it?

I don't understand your use of "easier" here.  Shouldn't this rather be
"the easiest way to achieve this"?

-- 
David Kastrup

Re: (require 'cus-load) clobbers match-data

[Geoff Gole]

> I don't understand your use of "easier" here.  Shouldn't this rather be
> "the easiest way to achieve this"?

Perhaps I misread you. I thought you were saying something along the
lines of "every chunk of elisp that can possibly cause libraries to
load must save match data in order to be correct".

If not, then no problem.

Re: (require 'cus-load) clobbers match-data

[Glenn Morris]

Geoff Gole wrote:

> While trying to puzzle out bug 5533
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5533>, I've found that
> (require 'cus-load) will stomp on match data if the file is not
> already loaded:

I'm not sure that 5533 can reasonably be classed as a bug. It seems a
strange way to do a search-replace - what's wrong with M-x query-replace?

In general, there should be no expectation that any operation in Emacs
will preserve the match-data (unless it explicitly says so).

> Maybe require should save and restore the match data itself?

This would be completely unnecessary in the vast majority of cases.
Since a require can run arbitrary code, there should be no expectation
that it preserves match-data.

The usual answer to "why doesn't FOO preserve the match-data" is "the
code calling FOO should take care to preserve the match-data if it
cares about it", rather than "FOO should always preserve the
match-data".

Re: (require 'cus-load) clobbers match-data

[Davis Herring]

> In general, there should be no expectation that any operation in Emacs
> will preserve the match-data (unless it explicitly says so).
>
>> Maybe require should save and restore the match data itself?
>
> This would be completely unnecessary in the vast majority of cases.
> Since a require can run arbitrary code, there should be no expectation
> that it preserves match-data.

This may not have been the original point, but loading a library can be
the result of calling an autoloaded function, even one that advertises
that it preserves the match data.  In that case it makes sense for `load'
(or something else in that sequence) to save it; loading a file is
(typically) already expensive compared to `save-match-data'.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: (require 'cus-load) clobbers match-data

[Andreas Schwab]

"Davis Herring" <herring@lanl.gov> writes:

> This may not have been the original point, but loading a library can be
> the result of calling an autoloaded function

Autoloading already preserves match-data, so there is no bug here.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."