[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should save-match-data bind inhibit-changing-match-data to nil?
From: |
David Kastrup |
Subject: |
Re: Should save-match-data bind inhibit-changing-match-data to nil? |
Date: |
Fri, 30 Nov 2007 00:21:52 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) |
Richard Stallman <address@hidden> 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