Should save-match-data bind inhibit-changing-match-data to nil?

Should save-match-data bind inhibit-changing-match-data to nil?

[David Kastrup]

Hi, I was thinking about using inhibit-changing-match-data in replace.el
for a number of things.  Now the tricky part is what to do with
operations that can lead to the user switching windows and similar?  It
is an obvious fix to wrap them in save-match-data.  But one would need
to set inhibit-changing-match-data to t at the same time.

Is this something that save-match-data could/should do in general?
After all, there is not much of a point to save the match data (except
that it gets moved into markers instead of integers, which _is_ a
difference when the user is editing) when it can't change, anyway?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Should save-match-data bind inhibit-changing-match-data to nil?

[Richard Stallman]

    Hi, I was thinking about using inhibit-changing-match-data in replace.el
    for a number of things.  Now the tricky part is what to do with
    operations that can lead to the user switching windows and similar?  It
    is an obvious fix to wrap them in save-match-data.  But one would need
    to set inhibit-changing-match-data to t at the same time.

Could you give an example of the sort of scenario are you concerned with here?
Which operations are these?

    Is this something that save-match-data could/should do in general?

Sorry, I don't follow.  What is your proposal?

Re: Should save-match-data bind inhibit-changing-match-data to nil?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Hi, I was thinking about using inhibit-changing-match-data in replace.el
>     for a number of things.  Now the tricky part is what to do with
>     operations that can lead to the user switching windows and similar?  It
>     is an obvious fix to wrap them in save-match-data.  But one would need
>     to set inhibit-changing-match-data to t at the same time.

Uh, to nil I mean.

> Could you give an example of the sort of scenario are you concerned with here?
> Which operations are these?

(read-string "something")

>     Is this something that save-match-data could/should do in general?
>
> Sorry, I don't follow.  What is your proposal?

Something like the following sketch (the only change to the original
version is let-binding inhibit-changing-match-data to nil around the
body):

(defmacro save-match-data (&rest body)
  "Execute the BODY forms, restoring the global value of the match data.
The value returned is the value of the last form in BODY."
  ;; It is better not to use backquote here,
  ;; because that makes a bootstrapping problem
  ;; if you need to recompile all the Lisp files using interpreted code.
  (declare (indent 0) (debug t))
  (list 'let
	'((save-match-data-internal (match-data)) inhibit-changing-match-data)
	(list 'unwind-protect
	      (cons 'progn body)
	      ;; It is safe to free (evaporate) markers immediately here,
	      ;; as Lisp programs should not copy from save-match-data-internal.
	      '(set-match-data save-match-data-internal 'evaporate))))

The idea is that if some code does

(let (inhibit-changing-match-data)
   (while ...
     (save-match-data (call something else))
   ...
))

that the (call something else) not only is free to change the match data
(and it will get restored afterwards), but actually has a chance of
changing the match data in the first place.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Should save-match-data bind inhibit-changing-match-data to nil?

[Richard Stallman]

The idea of `inhibit-changing-match-data' is that you use it around
small pieces of code.  (We should make the documentation say that
clearly.)  So there is no need for anything to bind it helpfully to
nil for you.