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: Thu, 07 Apr 2011 12:29:07 -0400 Message-ID: <4D9DE653.8000208@mousecar.com> References: <4D90D85C.5060805@mousecar.com> <4D98EE5B.4080108@mousecar.com> <87vcytd5dn.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 1302193799 23654 80.91.229.12 (7 Apr 2011 16:29:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2011 16:29:59 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Apr 07 18:29:56 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 1Q7s5i-0006oT-9D for geh-help-gnu-emacs@m.gmane.org; Thu, 07 Apr 2011 18:29:54 +0200 Original-Received: from localhost ([127.0.0.1]:49924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7s5h-0005yn-Q0 for geh-help-gnu-emacs@m.gmane.org; Thu, 07 Apr 2011 12:29:53 -0400 Original-Received: from [140.186.70.92] (port=53576 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7s53-0005vF-UA for help-gnu-emacs@gnu.org; Thu, 07 Apr 2011 12:29:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q7s52-0001hf-LY for help-gnu-emacs@gnu.org; Thu, 07 Apr 2011 12:29:13 -0400 Original-Received: from mout.perfora.net ([74.208.4.195]:55551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q7s52-0001hX-HB for help-gnu-emacs@gnu.org; Thu, 07 Apr 2011 12:29:12 -0400 Original-Received: from dellap.mousecar.net (dsl093-011-016.cle1.dsl.speakeasy.net [66.93.11.16]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LyFqf-1Pt4SG0b1Z-015uPn; Thu, 07 Apr 2011 12:29:11 -0400 User-Agent: Thunderbird 2.0.0.24 (X11/20101213) In-Reply-To: <87vcytd5dn.fsf@puma.rapttech.com.au> X-Enigmail-Version: 0.96.0 OpenPGP: id=5AD091E7 X-Provags-ID: V02:K0:iIkd4OkzU+9tcr5K+YwC3hyp36P8JOgjFkE7eO7sfef xxoo+2RHTdgFEAdiFXoeqKTFZDThy2KYGzO2fMiWCNvg1U1kOw p/4jaL2wCi14JFB3ClkfVNDerWt8WS5OBxJasv6UPbO8DmdH5u JRVzoeIvv+ms7FSHeaARgOZmXoqfW9kF6jRDNzn1SX1Avpr1My 4LNRi/TsXcKnx5WEx4iK7IAyIsntjBNipxZBQduo5A= 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:80668 Archived-At: 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. >> > > Providing the code alway helps. While Stephan's points are valid and a > common error people make, I don't think it is the problem you are > seeing. Yes, providing the actual code is generally a good idea... it gives everyone something concrete to look at. But the function I was writing was too long to expect anyone to read and digest it in just a few minutes; it would also require a lot of explanation from me to help others to understand it; three or four ancillary functions play roles and so they would have to be included also; all of this required a specific kind of text file to work it on, so I would have need to include that also; and besides all this, the code was a very unappealing mess to look at, with all kinds of cruft commented out, sundry comments inserted here and there, and some code not formatted in the traditional fashion. In short, it would have been too much work for everyone. So I thought just posting the directly relevant code fragments would be more effective. When there's a working package, a version 0.0001, I'll post it on the web so anyone who's curious or wants to use it can do so. > > 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. > > Note also, you can get rid of some of those progns i.e. > > (when (re-search-forward aname-re-str head-text-end-pt t) > (setq aname-str (match-string 2)) > (setq head-text-nested (match-string 4)) > (when (string= head-text-nested "") > (setq head-text-nested (create-heading-text)) > (if (not (string= aname-str "")) > (replace-match head-text-nested t t nil 4) > (setq aname-str (create-aname head-text-nested)) > (replace-match head-text-nested t nil nil 4) > (replace-match aname-str t nil nil 2)))) > > Note that the 'else' part of an if form has an implicit progn, so by > revesing the condition test, we can eliminate that progn. The 'unless' > form can be used instead of 'when' if you want to reverse the logic of > what you are doing. Yeah, inverting the conditionals does remove the progn statements and makes the code shorter. I read quite a bit about conditionals in some of the docs... and someone here on this list explained about progn a bit for me also. But I wrote the code how I was thinking through the problem, much in the way Kernighan and Ritchie say happens naturally... I think it was in the "Introduction" to their book, "The C Programming Language". That "progn" statement does seem clunky... it took some getting used to using an entire word just to denote the beginning of a block of text. But I've adapted. In fact, now it's like a huge flag telling me, 'this is where the block of text begins which executes when the if statement above is true.' It makes it easier to find those if's too. Sometimes I almost wish there was a corresponding " > (Note above is untested, but intention should be clear) > > 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. In addition, I wrote a simple diagnostic function (a couple versions of it actually) to show me what, if anything, was matched and inserted this function at various points in the code. This confirmed that the searches and conditionals were functioning as I wanted. Something else was wiping out the subexpressions. I eventually traced the problem to the read-from-minibuffer function. For some reason it wipes out previously established subexpressions. I wasn't expecting that at all. > > Tim Tim, thanks for all the input... and everyone else too. Don't worry... there's quite a bit more code I need to write, so I'll most likely be posting more questions/problems in the upcoming. (Is that something anybody's worried about? :) )