From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Discrepancy in definition/use of match-data? Date: 14 Jun 2004 11:05:42 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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 1087204015 24161 80.91.224.253 (14 Jun 2004 09:06:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2004 09:06:55 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jun 14 11:06:42 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 1BZnQQ-0007t3-00 for ; Mon, 14 Jun 2004 11:06:42 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BZnQP-0001VA-00 for ; Mon, 14 Jun 2004 11:06:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BZnRI-0002Hh-7N for emacs-devel@quimby.gnus.org; Mon, 14 Jun 2004 05:07:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BZnR8-0002Fm-RJ for emacs-devel@gnu.org; Mon, 14 Jun 2004 05:07:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BZnR8-0002FD-43 for emacs-devel@gnu.org; Mon, 14 Jun 2004 05:07:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BZnR7-0002F1-Vt for emacs-devel@gnu.org; Mon, 14 Jun 2004 05:07:26 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BZnPa-0006RB-Vb for emacs-devel@gnu.org; Mon, 14 Jun 2004 05:05:51 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BZnPT-0005Yr-UN; Mon, 14 Jun 2004 05:05:44 -0400 Original-To: "Stephen J. Turnbull" In-Reply-To: <87vfhu20el.fsf@tleepslib.sk.tsukuba.ac.jp> Original-Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:24948 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24948 "Stephen J. Turnbull" writes: > >>>>> "rms" == Richard Stallman writes: > > rms> sjt writes: > > On the other hand, pretty much any time any Lisp code intervenes > between the return of the matching function and entry to the match > data access there is an opportunity for a hook or handler to be > called. > > rms> That is rather an exaggeration. > > Exaggeration, sure. But it contains a kernel of truth. Those things that run in hooks/handlers/whatever need to get wrapped in save-match-data, anyway. > rms> Most of the Lisp functions described in the manual cannot > rms> call any hook. > > True, but not relevant unless you know which ones they are. > Offhand, I don't, and the docstrings/source comments are less than > 100% reliable. Where the docstrings are not reliable, they need to get amended, obviously. > Anyway, I've implemented a last-match-succeeded flag (for debug > usage only) and check it in match_limits and Fmatch_data (when > XEmacs is configured for error-checking). If we catch anything that > looks relevant to GNU Emacs I'll report it here. Anyway, the args-out-of-range error that now gets thrown gives a basically completely irrelevant second value (with regard to identifying the error. Actually, the first value is also irrelevant unless it is negative). Could one replace that second value with the function causing the error instead, or would that be inconsistent with any known error handlers? Or should one throw a different error altogether in the case where match-data is called without a valid match ever having been done? Which one? As I said already, I have no clue about the error handling conventions. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum