[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] /srv/bzr/emacs/emacs-24 r111281: * progmodes/python.el
From: |
Stefan Monnier |
Subject: |
Re: [Emacs-diffs] /srv/bzr/emacs/emacs-24 r111281: * progmodes/python.el (python-info-current-defun): Fix failed |
Date: |
Wed, 20 Feb 2013 09:01:35 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
>> I suspect this is not The Right Place for the save-match-data, since we
>> should not assume that current-indentation won't also mess up the
>> match-data.
> FWIW this very small change corrected the python-info-current-defun behavior
> and was able to pass the test suite I've been working on.
I don't doubt it works, I'm just pointing out that it would be better to
place the save-match-data elsewhere. The general rule is: put the
save-match-data between the "match" and the corresponding "get
match-data" rather than around some code that might modify the match-data.
> So far my local test/automated/python-tests.el is covering
> indentation, movement and python-info-* functions completely. Would it
> be OK to introduce these tests into the emacs-24 branch?
Yes, it's OK to add files to emacs-24/test/...
> Now, I certainly wasn't expecting current-indentation could change
> match-data (could it?).
All functions can do it, except for those where it's blatantly obvious
they can't (e.g. `car', `cdr', `match-beginning'). And yes,
current-indentation probably can in sufficiently weird cases.
> If so, I feel that functions not expected[0] to mess
> with match-data should at least document it.
We should indeed document the small set of functions which are
guaranteed not to mess the match-data.
> In this regard, I have a change in the works that will cause python.el to
> stop messing with match-data so much (use of looking-at-p instead of
> looking-at and such), and document those functions that are intended to.
> If everyone agrees I could get this to the emacs-24 branch.
I generally recommend not to go down that route. Instead, just make sure
all the match-{beginning/end/string} calls come right after the
corresponding search, and if not, place a save-match-data around the
intermediate code.
Stefan