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

[David Kastrup <dak@gnu.org>]

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