From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Discrepancy in definition/use of match-data? Date: Wed, 16 Jun 2004 16:13:20 +0900 Organization: The XEmacs Project Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87brjkt1pr.fsf@tleepslib.sk.tsukuba.ac.jp> References: <87n03a7as9.fsf@tleepslib.sk.tsukuba.ac.jp> <87vfhx46lc.fsf@tleepslib.sk.tsukuba.ac.jp> <87vfhu20el.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1087370159 20698 80.91.224.253 (16 Jun 2004 07:15:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2004 07:15:59 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 16 09:15:50 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaUeE-0000bV-00 for ; Wed, 16 Jun 2004 09:15:50 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaUeE-0006Oh-00 for ; Wed, 16 Jun 2004 09:15:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaUfC-00071P-M6 for emacs-devel@quimby.gnus.org; Wed, 16 Jun 2004 03:16:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BaUf3-00071H-Sj for emacs-devel@gnu.org; Wed, 16 Jun 2004 03:16:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BaUf3-00070a-8C for emacs-devel@gnu.org; Wed, 16 Jun 2004 03:16:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaUf3-00070V-5X for emacs-devel@gnu.org; Wed, 16 Jun 2004 03:16:41 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BaUdo-0006fB-BF for emacs-devel@gnu.org; Wed, 16 Jun 2004 03:15:24 -0400 Original-Received: from [130.158.98.109] (helo=tleepslib.sk.tsukuba.ac.jp) by mx20.gnu.org with esmtp (Exim 4.34) id 1BaUcM-00022N-Jz for emacs-devel@gnu.org; Wed, 16 Jun 2004 03:13:57 -0400 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 3.36 #1 (Debian)) id 1BaUbo-00022b-00 for ; Wed, 16 Jun 2004 16:13:20 +0900 Original-To: emacs-devel@gnu.org In-Reply-To: <87vfhu20el.fsf@tleepslib.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 14 Jun 2004 14:06:58 +0900") User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (chayote, linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25021 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25021 >>>>> "sjt" == Stephen J Turnbull writes: sjt> Anyway, I've implemented a last-match-succeeded flag (for sjt> debug usage only) and check it in match_limits and sjt> Fmatch_data (when XEmacs is configured for error-checking). I've changed this so that Fmatch_data saves the state of that flag with the registers, and Fstore_match_data restores it. This is bogus if somebody uses an explicit call to match-data, but so far I've only seen explicit use of match-data in macros like save-match-data. Unfortunately external packages occasionally define similar macros, making it difficult to suppress hundreds of bogus warnings from functions that use those macros. sjt> If we catch anything that looks relevant to GNU Emacs I'll sjt> report it here. OK, I have tripped this in three functions so far. All of them look relevant to GNU Emacs. isearch.el (isearch-repeat): both calls to match-{beginning,end} font-lock.el (font-lock-fontify-keywords-region): all calls to match-{beginning,end} (font-lock-fontify-anchored-keywords): all calls to match-{beginning,end} The calls in isearch.el are part of logic I don't understand yet. It looks like a zero-length match is being used to determine whether the isearch-success flag is lying. It should be possible to fix this, but I don't know when I'll have time to do so. The calls in font-lock are used to fontify text. They are guarded by a proper test for success in the case of a MATCHER which is a regexp as far as I can tell. So I suspect that in fact a MATCHER which is a function is being passed in, and it succeeds even though the regexp match failed. This is probably cc-mode, and possibly emacs-lisp-mode too. In all cases guarding the calls to match-{beginning,end} with a test on last-match-succeeded seems to leave behavior unchanged, except that font-lock seems perceptibly faster for both C and Lisp. (I haven't tried to measure that yet, though.) Again, it's unlikely I'll have time to dig into this soon, so I'm reporting it now. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.