From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pascal Bourguignon Newsgroups: gmane.emacs.help Subject: Re: match-string debugging problem Date: 11 Mar 2005 00:40:14 +0100 Organization: [posted via Easynet Spain] Message-ID: <8764zzkr35.fsf@thalassa.informatimago.com> References: <87ekenmnv7.fsf@thalassa.informatimago.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110498506 24919 80.91.229.2 (10 Mar 2005 23:48:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 10 Mar 2005 23:48:26 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Mar 11 00:48:25 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D9XG3-0002CQ-6H for geh-help-gnu-emacs@m.gmane.org; Fri, 11 Mar 2005 00:40:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D9XV0-0007RD-KW for geh-help-gnu-emacs@m.gmane.org; Thu, 10 Mar 2005 18:55:26 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!info4.fnal.gov!nntp-server.caltech.edu!hammer.uoregon.edu!news.wind.surfnet.nl!humbolt.nl.linux.org!news.nl.linux.org!feeder.enertel.nl!nntpfeed-01.ops.asmr-01.energis-idc.net!fr.ip.ndsoftware.net!proxad.net!proxad.net!easynet-monga!easynet.net!easynet-post1!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-Lines: 88 Original-NNTP-Posting-Host: 62.93.174.79 Original-X-Trace: DXC=Z@W]mkA`7XJA2n7mC85`OOEY<>`XO4V7M>Uh List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org X-MailScanner-To: geh-help-gnu-emacs@m.gmane.org Xref: news.gmane.org gmane.emacs.help:24758 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:24758 Stephen Berman writes: > On 10 Mar 2005 18:06:52 +0100 Pascal Bourguignon wrote: > > > Stephen Berman 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? Infered from the doc of re-search-forward, match-string and save-match-data. > 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. 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). -- __Pascal Bourguignon__ http://www.informatimago.com/ The rule for today: Touch my tail, I shred your hand. New rule tomorrow.