[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: error in replace-match: "args out of range"

From: ken
Subject: Re: error in replace-match: "args out of range"
Date: Sat, 09 Apr 2011 00:56:42 -0400
User-agent: Thunderbird (X11/20101213)

On 04/07/2011 07:25 PM Tim X wrote:
> ken <address@hidden> writes:
>> On 04/04/2011 06:21 PM Tim X wrote:
>>> ken <address@hidden> writes:
>>>> On 04/03/2011 07:19 PM PJ Weisberg wrote:
>>>>> On 4/3/11, ken <address@hidden> 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 "".
>> ....

reply via email to

[Prev in Thread] Current Thread [Next in Thread]