From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel 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 Message-ID: References: <51245E0F.6080603@anue.biz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361368904 1215 80.91.229.3 (20 Feb 2013 14:01:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 14:01:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Fabi=E1n?= Ezequiel Gallina Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 15:02:06 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U8AFJ-0000be-Sm for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 15:02:06 +0100 Original-Received: from localhost ([::1]:45479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8AEz-000193-9X for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 09:01:45 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8AEs-00018h-Fv for emacs-devel@gnu.org; Wed, 20 Feb 2013 09:01:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8AEq-0003Ed-Ia for emacs-devel@gnu.org; Wed, 20 Feb 2013 09:01:38 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:33178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8AEq-0003EY-Ei for emacs-devel@gnu.org; Wed, 20 Feb 2013 09:01:36 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFsoXXp/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNAcLFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFsoXXp/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNAcLFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="1805457" Original-Received: from 108-161-117-233.dsl.teksavvy.com (HELO pastel.home) ([108.161.117.233]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Feb 2013 09:01:34 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 405816CB99; Wed, 20 Feb 2013 09:01:35 -0500 (EST) In-Reply-To: <51245E0F.6080603@anue.biz> (=?iso-8859-1?Q?=22Fabi=E1n?= Ezequiel Gallina"'s message of "Wed, 20 Feb 2013 02:24:31 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157205 Archived-At: >> 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