On 11 Mar 2005 00:40:14 +0100 Pascal Bourguignon <[EMAIL PROTECTED]> wrote:
> Stephen Berman <[EMAIL PROTECTED]> writes: > >> [...] >> >> (let ((mystring-list ())) >> >> (while (re-search-forward >> >> (concat "^" (regexp-quote mystring1) "\\(.+\\)" >> >> (regexp-quote mystring2) "$") >> >> (point-max) t) >> >> (setq mystring-list (append (list (match-string 1)) mystring-list))) >> >> (insert "\n") >> >> (setq mystring-list (reverse mystring-list)) >> >> (dolist (elt mystring-list) >> >> (insert elt " "))))) >> >> [...] >> In any case, what I did find is that I can in fact track match-string >> by explicitly entering the ordinary Lisp debugger at that point. So >> putting `(debug)' before `(match-string 1)' in the above code stops >> execution there and stepping into the function by pressing `d' returns >> the matched string. So if there's a bug, then it's only in Edebug. I >> couldn't find any relevant discussion in the Edebug section of the >> manual. So at the very least, the Elisp documentation could be more >> explicit on this issue. > > > My guess is that either: > > - Edebug matches regexp itself, and therefore erases the match-data, > (a save-match-data would be in order in Edebug), or > > - Edebug changes the current buffer, and therefore when it executes > (match-string 1), this functions refers the match-data of the Edebug > buffer instead of that of the original buffer > (a save-excursion would be in order in Edebug). > > I'd bet for the former, since save-excursion is more commonly used > than save-match-data... (save-excursion calls save-buffer). I'm going to file a bug report to see if someone can confirm or refute your conjecture. Even if there's no code bug, I think the failure to mention this behavior is at least a doc bug. Steve Berman _______________________________________________ Help-gnu-emacs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
