Re: match-string debugging problem

[Stephen Berman]

On 11 Mar 2005 00:40:14 +0100 Pascal Bourguignon <spam@mouse-potato.com> wrote:

> Stephen Berman <Stephen.Berman@gmx.net> 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