From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ken Newsgroups: gmane.emacs.help Subject: Re: error in replace-match: "args out of range" Date: Mon, 28 Mar 2011 14:50:04 -0400 Message-ID: <4D90D85C.5060805@mousecar.com> References: Reply-To: gebser@mousecar.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1301338927 27149 80.91.229.12 (28 Mar 2011 19:02:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2011 19:02:07 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Mar 28 21:02:03 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4HhQ-0003nq-Ot for geh-help-gnu-emacs@m.gmane.org; Mon, 28 Mar 2011 21:02:01 +0200 Original-Received: from localhost ([127.0.0.1]:60750 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4Hb4-0006S7-Hu for geh-help-gnu-emacs@m.gmane.org; Mon, 28 Mar 2011 14:55:26 -0400 Original-Received: from [140.186.70.92] (port=59466 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4HW2-0004FL-N5 for help-gnu-emacs@gnu.org; Mon, 28 Mar 2011 14:50:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4HW0-0007N0-Gv for help-gnu-emacs@gnu.org; Mon, 28 Mar 2011 14:50:14 -0400 Original-Received: from mout.perfora.net ([74.208.4.195]:64977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4HW0-0007Md-Cf for help-gnu-emacs@gnu.org; Mon, 28 Mar 2011 14:50:12 -0400 Original-Received: from dellap.mousecar.net (dsl093-011-016.cle1.dsl.speakeasy.net [66.93.11.16]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MFcXl-1QA4wV2mV3-00EjPG; Mon, 28 Mar 2011 14:50:09 -0400 User-Agent: Thunderbird 2.0.0.24 (X11/20101213) In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=5AD091E7 X-Provags-ID: V02:K0:9zxlC7x768z/N9tyMY5MMNp8taDJiDtUKMLWoZIiaz0 YfhuSuaUPt89uwX056TUMYz978kJA5uEzj2nx1aILJwxrnPLwc TFVwKqyEqsJnAWV4OsqVmCuYncGO1s1EiyRceL/tBKS88SFLb3 pLcNbD6TFe1g82JQEKJbFvI66JdusQufDyOcOt/q92uzEvVhte myAU2jvrB6PJSsuayEYE6nlV1KMWOPersgNAODHxvg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.208.4.195 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 Xref: news.gmane.org gmane.emacs.help:80490 Archived-At: On 03/28/2011 11:38 AM Stefan Monnier wrote: >> eval((replace-match head-text-nested t nil head-text 4)) > > There's your problem right there: replace-match operates on the > match-data "returned" (i.e. set up) by the previous regexp match. > Now regexp matches happen *all the time* in Emacs, so the match-data > gets changed continuously. So your above command will, maybe, > sometimes, operate on the match-data you want, but other times it will > operate on the match-data corresponding to some other regexp-match > you're not even aware of. > > The only way to use replace-match reliably is to do it in the same piece > of code that did the regex-match and make sure nothing of importance > happens in between. Going back to the top-level is not "nothing of > importance" since it'll run various hooks, may run pending timers, > process filters, plus cause redisplay which may call font-lock, etc... > > > Stefan Stefan, Thanks for your reply. I know that the error occurs on that line. What I'm trying to figure out is what to change on that line to correct the problem... resolve the error. I understand that another search-- one invoked since the subexpressions were set for the above-cited replace-match-- will render ineffective those subexpressions. However, this replace-match (and others used in the same function) occurs after the relevant search and there is no other search occurring in between. In fact, the relevant search (the one where the relevant replace-match sets needed subexpressions) is the *last* one in this function. Moreover, I've run this function through edebug and when I evaluate the individual variables inside the above-cited replace-match, those variables do evaluate to the desired values. Now I'm trying to understand what you're saying in your last sentence above. Are you saying that another search invoked by emacs and outside of my code could alter the values of subexpressions of my last search? If so, this would counsel against ever using replace-match *ever* in any code. For this reason I don't think it's what you're saying, or what is actually confounding my replace-match. Besides this, as said, evaluating the values of the variables (excepting of course the final arg consisting of the subexpression number) shows that those variables contain expected values. Let me add that I've altered the args to the above replace-match and get the same error message. Strangely the out-of-range args are "-1 -1". What does that particular couple of numbers signify? Thanks again for the reply.