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: 11 Jun 2004 10:54:05 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87n03a7as9.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 1086944079 26441 80.91.224.253 (11 Jun 2004 08:54:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Jun 2004 08:54:39 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Jun 11 10:54:27 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 1BYhnv-00019G-00 for ; Fri, 11 Jun 2004 10:54:27 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BYhnv-000251-00 for ; Fri, 11 Jun 2004 10:54:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BYhoe-0006yZ-En for emacs-devel@quimby.gnus.org; Fri, 11 Jun 2004 04:55:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BYhoR-0006yF-9S for emacs-devel@gnu.org; Fri, 11 Jun 2004 04:54:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BYhoP-0006xw-V1 for emacs-devel@gnu.org; Fri, 11 Jun 2004 04:54:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BYhoP-0006xt-NQ for emacs-devel@gnu.org; Fri, 11 Jun 2004 04:54:57 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BYhnb-00036j-Tj for emacs-devel@gnu.org; Fri, 11 Jun 2004 04:54:08 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BYhnb-0001IN-60; Fri, 11 Jun 2004 04:54:07 -0400 Original-To: "Stephen J. Turnbull" In-Reply-To: <87n03a7as9.fsf@tleepslib.sk.tsukuba.ac.jp> Original-Lines: 51 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:24823 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24823 "Stephen J. Turnbull" writes: > >>>>> "David" == David Kastrup writes: > > David> Now the obvious solution to that would be to make > David> unsuccessful matches void the match-data, too. I myself > David> have no recollection of any discussions about this, but > David> Stephen Turnbull was pretty vocal about having proposed > David> something like this, > > To be precise, I tried it in a workspace and was immediately slapped > down by a regression test failure. That in itself does not constitute a decision. It suggests that such a change should probably not be made lightly, and not shortly before a release. But it does not preclude a long-term strategy of change if one can agree on the desirability: one would start by actively declaring this usage deprecated (if it ever was supposed to be allowed in the first place). At what time one actually clamps down the code is unrelated to the question of whether it is desirable to do so. How strong were the results from the regression test? What kind and amount of code appears to be affected? > David> What I'll do right now is just changing the condition > David> that it will not flag an error for > David> greater-than-encountered match-data indices, except for > David> the case of completely void match-data where I'll still > David> flag an error. > > I would suggest improving the error message if at all possible, and > documenting this prominently, as it is likely to happen very rarely, > and then only in asynchronous calls. With the current code. But I was also proposing to void the match-data in the main loop: that would produce errors more often, and only in situations where the match-data was completely unpredictable to start with (and possibly undefined, too). I have no clue about the involved complexity: if this leads to a danger of, say, recursive-edit or debug not working like before, one should postpone till after release. Anyway, I do not know enough about the error handling in C to propose better error handling or messages. I do agree that the currently generated message is dissatisfactorily obtuse. In particular, since the context flagged in the traceback is the caller, and not the particular function itself, so it is guesswork to figure out just _what_ function triggered the "out of range" error. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum