read-from-minibuffer & match data

read-from-minibuffer & match data

[Joost Kremers]

Hi,

The other day I started experiencing a problem with code that has been
working just fine for about nine months now. Turns out the problem was
caused by read-from-minibuffer changing the match data. (Basically, I
had a call to read-from-minibuffer after calling string-match and before
calling replace-match.)

Since this code has been working fine for nine months for me and I
haven't had any complaints from others using the code, and since I keep
up-to-date with emacs snapshot releases, I suspect a recent change to
emacs caused this problem.

So now I'm wondering: has there been a recent change to
read-from-minibuffer (or code underlying it) that causes the match data
to change and if so, should this be considered a bug? Or is
read-from-minibuffer simply not guaranteed not to touch the match data,
meaning there is a bug in my code and I have just been lucky that this
hasn't bitten me before?

I've put a save-match-data into the function to solve the issue, but I'd
just like to make sure this isn't a bug in emacs.

TIA

-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

RE: read-from-minibuffer & match data

[Drew Adams]

> I've put a save-match-data into the function to solve the 
> issue, but I'd just like to make sure this isn't a bug in emacs.

The way to make sure is to file a bug report, preferably with a recipe starting
from `emacs -Q'.

Emacs Dev will take a look and let you know their opinion.
(You will still be free to hold your own opinion, of course. ;-))

Re: read-from-minibuffer & match data

[Stefan Monnier]

> I've put a save-match-data into the function to solve the issue, but I'd
> just like to make sure this isn't a bug in emacs.

No, you've just been lucky until now.  The general rule is that any
function is liable to thrash the match-data, except for some exceptions,
most of which are primitives such as car/cdr/aset/aref, match-string,
etc...


        Stefan

RE: read-from-minibuffer & match data

[Drew Adams]

> > I've put a save-match-data into the function to solve the 
> > issue, but I'd just like to make sure this isn't a bug in emacs.
> 
> No, you've just been lucky until now.  The general rule is that any
> function is liable to thrash the match-data, except for some 
> exceptions, most of which are primitives such as car/cdr/aset/aref,
> match-string, etc...

That is the general rule, yes, and it is appropriate.

But is it a reason that `read-from-minibuffer' should start thrashing the
match-data, if it has not done so in the past?

That was the point, I think: to make sure that Emacs Dev is aware of this
change.  If it is intentional, that's one thing; if not, perhaps it
represents/indicates a bug somewhere.

But I guess you are implicitly confirming that you have checked and the
thrashing is necessary or at least intentional.

Re: read-from-minibuffer & match data

[Stefan Monnier]

> But is it a reason that `read-from-minibuffer' should start thrashing the
> match-data, if it has not done so in the past?

I don't think it's new that read-from-minibuffer thrashes the
match-data.  Maybe it did it less often in the past.


        Stefan

RE: read-from-minibuffer & match data

[Drew Adams]

> > But is it a reason that `read-from-minibuffer' should start 
> > thrashing the match-data, if it has not done so in the past?
> 
> I don't think it's new that read-from-minibuffer thrashes the
> match-data.  Maybe it did it less often in the past.

I don't know either (which is why I said "if").

Re: read-from-minibuffer & match data

[Joost Kremers]

Drew Adams wrote:
>> I've put a save-match-data into the function to solve the 
>> issue, but I'd just like to make sure this isn't a bug in emacs.
>
> The way to make sure is to file a bug report, preferably with a recipe starting
> from `emacs -Q'.

Sorry, I should have tested with `emacs -Q' before posting of course...
Turns out that it is not Emacs itself but a package I started using
recently, autopair. With `emacs -Q' read-from-minibuffer does not affect
the match data. If I then load autopair.el and activate it globally
(autopair-global-mode), read-from-minibuffer suddenly does chang the
match data.

However, given that there is apparently no good reason to assume that
read-from-minibuffer never changes the match data, I have to consider
this a bug in my code, so I'll keep the fix I added.

Still, I'll notify the developer of autopair, so he can decide for
himself if he should do something about it.

Thanks to all who replied in this thread. :-)

-- 
Joost Kremers                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: read-from-minibuffer & match data

[Barry Margolin]

In article 
<slrnkd3ck6.m2k.joostkremers@j.kremers4.news.arnhem.chello.nl>,
 Joost Kremers <joostkremers@yahoo.com> wrote:

> Still, I'll notify the developer of autopair, so he can decide for
> himself if he should do something about it.

Why should he do something? If he needs to use string-match in his 
implementation, what's wrong with that?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: read-from-minibuffer & match data

[Joost Kremers]

Barry Margolin wrote:
> In article 
> <slrnkd3ck6.m2k.joostkremers@j.kremers4.news.arnhem.chello.nl>,
>  Joost Kremers <joostkremers@yahoo.com> wrote:
>
>> Still, I'll notify the developer of autopair, so he can decide for
>> himself if he should do something about it.
>
> Why should he do something? If he needs to use string-match in his 
> implementation, what's wrong with that?

I'm not saying he should, that's up to him to decide. I'm not
knowledgeable enough to have an opinion on the matter.

But on the face of it, autopair has nothing to do with
read-from-minibuffer, so that makes me wonder whether similar unexpected
interactions could happen with other parts of Emacs. The maintainer of
autopair is much better able to decide that than I am.


-- 
Joost Kremers                                  joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: read-from-minibuffer & match data

[Barry Margolin]

In article 
<slrnkd49ne.m2k.joostkremers@j.kremers4.news.arnhem.chello.nl>,
 Joost Kremers <joostkremers@yahoo.com> wrote:

> Barry Margolin wrote:
> > In article 
> > <slrnkd3ck6.m2k.joostkremers@j.kremers4.news.arnhem.chello.nl>,
> >  Joost Kremers <joostkremers@yahoo.com> wrote:
> >
> >> Still, I'll notify the developer of autopair, so he can decide for
> >> himself if he should do something about it.
> >
> > Why should he do something? If he needs to use string-match in his 
> > implementation, what's wrong with that?
> 
> I'm not saying he should, that's up to him to decide. I'm not
> knowledgeable enough to have an opinion on the matter.
> 
> But on the face of it, autopair has nothing to do with
> read-from-minibuffer, so that makes me wonder whether similar unexpected
> interactions could happen with other parts of Emacs. The maintainer of
> autopair is much better able to decide that than I am.

I don't think it has anything to do specifically with the minibuffer. I 
think typing anywhere will do it. autopair's post-command-hook uses 
string-match. Also, autopair-on uses it, and it's called as part of 
switching into buffers to enable/disable the minor mode.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***