Possible bug in `match-string` in 24.4.50.18?

Possible bug in `match-string` in 24.4.50.18?

[Alexis]

Hi all,

i couldn't see any reference to this issue in the bug-gnu-emacs archives of
recent weeks.

Take the following code:

    (setq address "mailto:alexis@example.com")
    (setq re "mailto")
    (string-match re address)
    (match-string 0 address)

In 24.3, the call to `string-match` correctly returns 0, and the call to
`match-string` correctly returns "mailto".

In 24.4.50.18 (more specifically, git commit
08005cbfff9227ac73cbee5f3f5afa65f8c27849), the call to `string-match`
correctly returns 0, but the call to `match-string` consistently returns
"m" instead of "mailto".

Am i doing something wrong, is there an issue with my local setup, or is
this a bug?


Alexis.

Re: Possible bug in `match-string` in 24.4.50.18?

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Sun, 25 May 2014 14:33:22 +1000
> 
>     (setq address "mailto:alexis@example.com")
>     (setq re "mailto")
>     (string-match re address)
>     (match-string 0 address)
> 
> In 24.3, the call to `string-match` correctly returns 0, and the call to
> `match-string` correctly returns "mailto".
> 
> In 24.4.50.18 (more specifically, git commit
> 08005cbfff9227ac73cbee5f3f5afa65f8c27849), the call to `string-match`
> correctly returns 0, but the call to `match-string` consistently returns
> "m" instead of "mailto".
> 
> Am i doing something wrong, is there an issue with my local setup, or is
> this a bug?

I cannot reproduce this with today's trunk.  Does it happen to you in
"emacs -Q"?

Re: Possible bug in `match-string` in 24.4.50.18?

[Alexis]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alexis <flexibeast@gmail.com>
>> Date: Sun, 25 May 2014 14:33:22 +1000
>> 
>>     (setq address "mailto:alexis@example.com")
>>     (setq re "mailto")
>>     (string-match re address)
>>     (match-string 0 address)
>> 
>> In 24.3, the call to `string-match` correctly returns 0, and the call to
>> `match-string` correctly returns "mailto".
>> 
>> In 24.4.50.18 (more specifically, git commit
>> 08005cbfff9227ac73cbee5f3f5afa65f8c27849), the call to `string-match`
>> correctly returns 0, but the call to `match-string` consistently returns
>> "m" instead of "mailto".
>> 
>> Am i doing something wrong, is there an issue with my local setup, or is
>> this a bug?
>
> I cannot reproduce this with today's trunk.  Does it happen to you in
> "emacs -Q"?

It does; the above results were derived from running both 24.4.50.18 and
24.3 with the -Q option. However, putting the code inside a `let` as
suggested by Stefan does result in the correct output being produced.


Alexis.

Re: Possible bug in `match-string` in 24.4.50.18?

[Stefan Monnier]

> Take the following code:

>     (setq address "mailto:alexis@example.com")
>     (setq re "mailto")
>     (string-match re address)
>     (match-string 0 address)

These are 4 separate expressions.  How do you run them?
My crystal ball says that the problem is the code you unknowingly run
between each one of those expressions.  If you run them as a single
expression such as

    (let ((address "mailto:alexis@example.com")
          (re "mailto"))
      (if (string-match re address)
          (match-string 0 address)))

I'm pretty sure you'll get what you want.


        Stefan

Re: Possible bug in `match-string` in 24.4.50.18?

[Alexis]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Take the following code:
>
>>     (setq address "mailto:alexis@example.com")
>>     (setq re "mailto")
>>     (string-match re address)
>>     (match-string 0 address)
>
> These are 4 separate expressions.  How do you run them?

i was playing around in *scratch*, to test out various regular
expressions on my data, and did a C-x C-e after each line. The above was
the result of whittling down the problem to the simplest case i could
find that exhibited the problem. There was nothing else in the buffer,
and as i noted to Eli, i was indeed running with the -Q option.

> My crystal ball says that the problem is the code you unknowingly run
> between each one of those expressions.  If you run them as a single
> expression such as
>
>     (let ((address "mailto:alexis@example.com")
>           (re "mailto"))
>       (if (string-match re address)
>           (match-string 0 address)))
>
> I'm pretty sure you'll get what you want.

It seems you're right. :-) Thank you!

i now note that this situation is indeed described in the GNU Emacs Lisp
Reference Manual:

"Notice that all functions are allowed to overwrite the match data
unless they're explicitly documented not to do so. A consequence is that
functions that are run implicitly in the background (see Timers, and
Idle Timers) should likely save and restore the match data explicitly."

.... which i hadn't read because i'd only been reading section "34.6.2
Simple Match Data Access":

"Every successful search sets the match data. Therefore, you should
query the match data immediately after searching, before calling any
other function that might perform another search."

.... which is what i thought my code was doing.

Since the latter text is from a reference manual which, i suspect, other
people will often use by simply reading specific function documentation,
could i suggest adding to the latter text something along the lines of:

"Note that all functions are allowed to overwrite the match data unless
they're explicitly documented not to do so. A consequence is that
functions that are run implicitly in the background might overwrite your
match data unless you wrap your matching function (e.g. string-match)
and match-string together in a let."

Thanks again!


Alexis.

Re: Possible bug in `match-string` in 24.4.50.18?

[Stefan Monnier]

>> These are 4 separate expressions.  How do you run them?
> i was playing around in *scratch*, to test out various regular
> expressions on my data, and did a C-x C-e after each line.

C-x C-e itself might overwrite the match data while looking at the
buffer to decide what to evaluate.  And after running that command, tons
of other code is run, such as post-command-hook, process-filters,
timers, pre-redisplay-function and whatnot, all of which will gladly
overwrite the match-data.


        Stefan

Re: Possible bug in `match-string` in 24.4.50.18?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> These are 4 separate expressions.  How do you run them?
>> i was playing around in *scratch*, to test out various regular
>> expressions on my data, and did a C-x C-e after each line.
>
> C-x C-e itself might overwrite the match data while looking at the
> buffer to decide what to evaluate.  And after running that command, tons
> of other code is run, such as post-command-hook, process-filters,
> timers, pre-redisplay-function and whatnot, all of which will gladly
> overwrite the match-data.

Most but possibly not all of them are run in an implicit
save-match-data.

-- 
David Kastrup

Re: Possible bug in `match-string` in 24.4.50.18?

[Alexis]

Stefan Monnier writes:

>>> These are 4 separate expressions.  How do you run them?
>> i was playing around in *scratch*, to test out various regular
>> expressions on my data, and did a C-x C-e after each line.
>
> C-x C-e itself might overwrite the match data while looking at the
> buffer to decide what to evaluate.

Oh okay.

> And after running that command, tons
> of other code is run, such as post-command-hook, process-filters,
> timers, pre-redisplay-function and whatnot, all of which will gladly
> overwrite the match-data.

*nod* - Thanks for explaining!


Alexis.