From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.help Subject: Re: match-string debugging problem Date: Fri, 11 Mar 2005 23:18:06 +0100 Message-ID: <873bv1omht.fsf@nolde.local.home> References: <87ekenmnv7.fsf@thalassa.informatimago.com> <8764zzkr35.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 1110580810 18614 80.91.229.2 (11 Mar 2005 22:40:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2005 22:40:10 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Mar 11 23:40:09 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D9smL-0006Gi-Le for geh-help-gnu-emacs@m.gmane.org; Fri, 11 Mar 2005 23:38:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D9t1V-0005HA-Kj for geh-help-gnu-emacs@m.gmane.org; Fri, 11 Mar 2005 17:54:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D9t1F-0005GE-4c for help-gnu-emacs@gnu.org; Fri, 11 Mar 2005 17:54:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D9t07-000592-9N for help-gnu-emacs@gnu.org; Fri, 11 Mar 2005 17:53:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D9t05-00051Y-GM for help-gnu-emacs@gnu.org; Fri, 11 Mar 2005 17:52:57 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1D9sUA-00052t-IJ for help-gnu-emacs@gnu.org; Fri, 11 Mar 2005 17:19:58 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1D9sTC-0004BQ-38 for help-gnu-emacs@gnu.org; Fri, 11 Mar 2005 23:18:58 +0100 Original-Received: from pd957cd2b.dip0.t-ipconnect.de ([217.87.205.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Mar 2005 23:18:58 +0100 Original-Received: from Stephen.Berman by pd957cd2b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Mar 2005 23:18:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: help-gnu-emacs@gnu.org Original-Lines: 45 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd957cd2b.dip0.t-ipconnect.de User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor 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:24778 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:24778 On 11 Mar 2005 00:40:14 +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 " "))))) >> >> [...] >> 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