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: Sat, 09 Apr 2011 00:56:42 -0400 Message-ID: <4D9FE70A.8010806@mousecar.com> References: <4D90D85C.5060805@mousecar.com> <4D98EE5B.4080108@mousecar.com> <87vcytd5dn.fsf@puma.rapttech.com.au> <87k4f5d4p6.fsf@puma.rapttech.com.au> 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 1302325058 22225 80.91.229.12 (9 Apr 2011 04:57:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Apr 2011 04:57:38 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Tim X Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Apr 09 06:57:34 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 1Q8QEo-0006na-22 for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Apr 2011 06:57:34 +0200 Original-Received: from localhost ([127.0.0.1]:36084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8QEn-0002YF-1y for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Apr 2011 00:57:33 -0400 Original-Received: from [140.186.70.92] (port=39177 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8QE8-0002Tp-0A for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 00:56:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8QE6-0001eA-Mz for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 00:56:51 -0400 Original-Received: from mout.perfora.net ([74.208.4.195]:53930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8QE6-0001e0-Il for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 00:56:50 -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 0LxQ26-1PsFzl2bxi-0170lH; Sat, 09 Apr 2011 00:56:46 -0400 User-Agent: Thunderbird 2.0.0.24 (X11/20101213) In-Reply-To: <87k4f5d4p6.fsf@puma.rapttech.com.au> X-Enigmail-Version: 0.96.0 OpenPGP: id=5AD091E7 X-Provags-ID: V02:K0:A6zNbI9jE6173pme3jc81VO1P8EeWls0yTfCOrBlBY/ wV2RfwOWc2nxiSb9LK4oBSXvIYLlMq2EEdNUnjMpjvayRU4Kte 03s4vn7nXbiFMlmoPjIaeBS05XXkx7SQyY/VNeJO7IuW7FDE29 Hd1+Y64Rz8gDdn0JZ7nG7ddtzoq4oWANqfvYv+AO9S86gEqJkn +w8A2OigQu6GnhYxg5v4XaMgWxhnJ4QR/0lMMw7NOE= 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:80726 Archived-At: On 04/07/2011 07:25 PM Tim X wrote: > ken writes: > >> On 04/04/2011 06:21 PM Tim X wrote: >>> ken writes: >>> >>>> On 04/03/2011 07:19 PM PJ Weisberg wrote: >>>>> On 4/3/11, ken wrote: >>>>>> On 03/28/2011 04:32 PM Stefan Monnier wrote: >>>>>>> I'm just saying that >>>>>>> >>>>>>> M-: (some-regexp-search) RET >>>>>>> M-: (replace-match ...) RET >>>>>>> >>>>>>> won't always do what you want, because a whole lot of code will run >>>>>>> between the two. >>>>>>> >>>>>>> >>>>>>> Stefan >>>> .... >>>> >>>> So, yes, the search and replace-match are in the same function. Are >>>> they "close together"? I'd say yes, but that's a judgment call really. >>>> The string I want to replace in this particular instance is a null string. >>>> >>> .... > >>> It would help to see the regexp you are using to test this. Note that >>> match-string returns nil if the subexpression you are asking for did not >>> exist. If the subexpression did not exist, what would replace-match >>> replace as there is no match? >> Tim, this is a valid point generally, but not in this instance. The >> code included conditionals for each search and so if the search failed >> to find the sought RE, a different block of code would be executed. And >> there was a block of code to cover each of the five possible conditions. >> > > The reason I asked for a copy of the regexp is that regexps can be > tricky and it really helps to also have, in addtion to the code, the > regexp being used as input when the code generates the error. > > For example, you can have a regexp with one or more subexpression that does not > match while your overall regexp did match. According to the docs, in > that case, match-string would return nil when queried for the > subexpressions and not "". Note that "" and nil are not > the same. Depending on your regexp, both aname-str and head-text-nested > could have the value nil. However, your conditional statements that use > these variables only check for "", which is not the same as nil and > therefore could be returning true/false unexpectedly and causing the > wrong branch to be executed. > > This may or may not be an issue, depending on your regexp. > >>> .... >>> >>> My guess is that it does not work because replace-match has no idea what >>> it is yhou want to match as the subexpression was not found i.e. is not >>> in the string, so it has no way to know where in the string to do the >>> replace. >> When the subexpression isn't found, then the search fails. When the >> search fails, then a different code block executes, one which doesn't >> require the existence of that subexpression. >> > > This was my point of warning. It is quite possible to have > regexps where sub expressions are not found, but the overall regexp > succeeds. I'm having a hard time with that concept. Is there a small bit of example code you could show it with? > This means that the regexp-search-* will succeed, but the > functions to extract the subexpressions will return nil. As we dind't > have an example of the regexp you are using, it is not possible to know > in this case if this is an issue or not. If your code will allow the > user to define the regexp, you would need to test for nil and not just "". > >> ....