On 10 Mar 2005 18:06:52 +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 " "))))) >> >> After evalling this code and typing `M-x mystring-list', buffer *test* >> consists of these lines: >> >> +++++ test1 ~~~~~ >> +++++ test2 ~~~~~ >> +++++ test3 ~~~~~ >> +++++ test4 ~~~~~ >> +++++ test5 ~~~~~ >> test1 test2 test3 test4 test5 >> >> The last line indicates that match-string correctly matches the >> strings that build mystring-list. But when I step through the code >> with edebug, match-string always returns nil and a wrong-type-argument >> error is raised at the insert (since nil is not char-or-string-p). >> (Edebug isn't the problem: evalling first the regexp search code in >> *test* and then (match-string 1) also returns nil.) Because of this >> I'm having a hard time debugging other code that uses match-string. >> Can someone explain what's going on? > > re-search-forward uses global state (buffer, matched range, etc) as > match-data, to communicate with match-string. When you're debugging, > this global state is switched or modified. One could consider it a > bug in the debugger. > > See: match-data > save-match-data > save-excursion > save-buffer How do you know about this state difference? I couldn't find any mention of it in the documentation of the functions you mention, nor elsewhere in the Elisp manual (CVS version). I glanced through the comments in search.c but didn't see anything obviously (to me) relevant. If it's defined in the C source code I'd appreciate a pointer, even though I probably wouldn't be able to understand it at present. 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. Steve Berman _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
