[EMAIL PROTECTED] (Kim F. Storm) writes: > [EMAIL PROTECTED] (Kim F. Storm) writes: > >> >> Which brings me to the suggestion that we add an optional arg to >> set-match-data like this: >> >> (set-match-data list &optional destroy-markers) >> >> and change save-match-data to use it >> >> (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))) >> (list 'unwind-protect >> (cons 'progn body) >> '(set-match-data save-match-data-internal t)))) > > I made the change slightly different to avoid adding another arg to > Fset_match_data, which causes problems at C level. Instead, if first > arg to match-data is 'evaporate', set-match-data will eventually free > markers on the resulting list...
So if INTEGERS is 'evaporate, we don't get integers but markers, and those will be unseated at restore time. In addition, the list will get prolonged by one additional member. This is probably not too tragic since I don't see anybody else accessing a data structure created with (set-match-data 'evaporate), but it is hardly an element of beauty. Should not (match-data whatever '(evaporate marker1 marker2 ...)) also clean up the markers passed in for reuse? Anyway, allow me to throw a fit. The whole match-data thing was ugly previously, but this surely takes the cake, platter and all. At the very least, the INTEGERS argument should be renamed to something more in line with the new function. But I don't like that interface at all, really. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel