From unknown Sat Jun 21 03:04:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#19954: python.el: more consistent sexp navigation Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: fgallina@gnu.org, bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Feb 2015 17:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 19954 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 19954@debbugs.gnu.org Cc: fgallina@gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: fgallina@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14249716123834 (code B ref -1); Thu, 26 Feb 2015 17:27:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Feb 2015 17:26:52 +0000 Received: from localhost ([127.0.0.1]:58882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YR2D5-0000zl-ND for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52763) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YR2D3-0000zY-DL for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR2Cs-0007vp-9A for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:43 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2Cs-0007vj-70 for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:38 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2Cn-00085M-Ce for bug-gnu-emacs@gnu.org; Thu, 26 Feb 2015 12:26:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR2Ch-0007uW-PE for bug-gnu-emacs@gnu.org; Thu, 26 Feb 2015 12:26:33 -0500 Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:36199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2Ch-0007tw-ID for bug-gnu-emacs@gnu.org; Thu, 26 Feb 2015 12:26:27 -0500 Received: by labgq15 with SMTP id gq15so12500754lab.3 for ; Thu, 26 Feb 2015 09:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=VOr4yptZBzr3HJpexUvNIxuoGqKZTC1T6eDaZSiPpLY=; b=Qdcp/nHetfxfhuFfrS82RkkqxSYxS8dt2LNP/3oGsVpftcvoJdsqRL26QnDCcKbaGU PW1HKvWFfPgdqceCEqtN7/IQ/IrhH8ooYhNxKYO+6gohy0sc4twpQjthl2ysei3wll+p ROmnDn0Zaj08ggN6ZovK0p5B6FlsTVNLuD6qXZ9ul+69j/Ij1wlRDu8adVy8lM0/t4wP JbTvtWiht+TU4HFY829JqSTMCm5ioMcQQMpj4ruglKbW23mzxQCRao0y89cqxet+KJDz InDELTAZnKiK3zzLhF8bn16efY6IEzDjdK0F7SSAwUyRVDYCINviCGTJ9ohSRXRq2K84 Ma9Q== X-Received: by 10.112.170.100 with SMTP id al4mr8844617lbc.42.1424971586042; Thu, 26 Feb 2015 09:26:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.6.74 with HTTP; Thu, 26 Feb 2015 09:26:04 -0800 (PST) From: Carlos Pita Date: Thu, 26 Feb 2015 14:26:04 -0300 Message-ID: Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) X-Debbugs-CC: fgallina@gnu.org If this is a feature I recognize I don't understand the rationally behind it: [...] (and (not forward-p) (eq (syntax-class (syntax-after (1- (point)))) (car (string-to-syntax ")"))))) ;; Inside a paren or looking at it, lisp knows what to do. Say * is the point. The inconsistency I find is that C-M-left will do very different things while at the end of different lines: A) from sklearn.cross_validation import KFold* --> *from sklearn.cross_validation import KFold B) n = len(train.y)* --> n = len*(train.y) I think the intention is to nav at the "statement/block level" when the point is at the end of the line. The difference of behaviour between A and B can't be reconciled at any level: sexp, list, statement, block. My expectation would be: B') n = len(train.y)* --> *n = len(train.y) B'') n = len(train.y*) --> n = len(train.*y) Notice that this is even more conspicuous at the end of a block: C) for x in range(0, 10): x = 2 print("hello")* --> for x in range(0, 10): x = 2 print*("hello") D) for x in range(0, 10): print("hello") x = 2* --> *for x in range(0, 10): print("hello") x = 2 I vote for removing the (syntax-after (1- (point)) special case as IMO it only adds confussion to the already complex nav rules. Cheers -- Carlos From unknown Sat Jun 21 03:04:52 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Carlos Pita Subject: bug#19954: closed (python.el: more consistent sexp navigation) Message-ID: References: <87egnog5t7.fsf@gnu.org> X-Gnu-PR-Message: they-closed 19954 X-Gnu-PR-Package: emacs Reply-To: 19954@debbugs.gnu.org Date: Mon, 13 Apr 2015 01:45:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1428889503-748-1" This is a multi-part message in MIME format... ------------=_1428889503-748-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #19954: python.el: more consistent sexp navigation which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 19954@debbugs.gnu.org. --=20 19954: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19954 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1428889503-748-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 19954-done) by debbugs.gnu.org; 13 Apr 2015 01:44:59 +0000 Received: from localhost ([127.0.0.1]:54284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YhTQo-0000Bj-Rt for submit@debbugs.gnu.org; Sun, 12 Apr 2015 21:44:59 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:57598 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YhTQn-0000Bc-BD for 19954-done@debbugs.gnu.org; Sun, 12 Apr 2015 21:44:57 -0400 Received: from [190.246.172.180] (port=38511 helo=localhost) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YhTQm-0001UG-4Q for 19954-done@debbugs.gnu.org; Sun, 12 Apr 2015 21:44:56 -0400 From: fgallina@gnu.org (=?utf-8?Q?Fabi=C3=A1n?= Ezequiel Gallina) To: 19954-done@debbugs.gnu.org Subject: python.el: more consistent sexp navigation Date: Sun, 12 Apr 2015 22:44:52 -0300 Message-ID: <87egnog5t7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 19954-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Fixed at 659609d in the master branch. Thanks, Fabi=C3=A1n. ------------=_1428889503-748-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 26 Feb 2015 17:26:52 +0000 Received: from localhost ([127.0.0.1]:58882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YR2D5-0000zl-ND for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52763) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YR2D3-0000zY-DL for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR2Cs-0007vp-9A for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:43 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2Cs-0007vj-70 for submit@debbugs.gnu.org; Thu, 26 Feb 2015 12:26:38 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2Cn-00085M-Ce for bug-gnu-emacs@gnu.org; Thu, 26 Feb 2015 12:26:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR2Ch-0007uW-PE for bug-gnu-emacs@gnu.org; Thu, 26 Feb 2015 12:26:33 -0500 Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:36199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2Ch-0007tw-ID for bug-gnu-emacs@gnu.org; Thu, 26 Feb 2015 12:26:27 -0500 Received: by labgq15 with SMTP id gq15so12500754lab.3 for ; Thu, 26 Feb 2015 09:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=VOr4yptZBzr3HJpexUvNIxuoGqKZTC1T6eDaZSiPpLY=; b=Qdcp/nHetfxfhuFfrS82RkkqxSYxS8dt2LNP/3oGsVpftcvoJdsqRL26QnDCcKbaGU PW1HKvWFfPgdqceCEqtN7/IQ/IrhH8ooYhNxKYO+6gohy0sc4twpQjthl2ysei3wll+p ROmnDn0Zaj08ggN6ZovK0p5B6FlsTVNLuD6qXZ9ul+69j/Ij1wlRDu8adVy8lM0/t4wP JbTvtWiht+TU4HFY829JqSTMCm5ioMcQQMpj4ruglKbW23mzxQCRao0y89cqxet+KJDz InDELTAZnKiK3zzLhF8bn16efY6IEzDjdK0F7SSAwUyRVDYCINviCGTJ9ohSRXRq2K84 Ma9Q== X-Received: by 10.112.170.100 with SMTP id al4mr8844617lbc.42.1424971586042; Thu, 26 Feb 2015 09:26:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.6.74 with HTTP; Thu, 26 Feb 2015 09:26:04 -0800 (PST) From: Carlos Pita Date: Thu, 26 Feb 2015 14:26:04 -0300 Message-ID: Subject: python.el: more consistent sexp navigation To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) X-Debbugs-CC: fgallina@gnu.org If this is a feature I recognize I don't understand the rationally behind it: [...] (and (not forward-p) (eq (syntax-class (syntax-after (1- (point)))) (car (string-to-syntax ")"))))) ;; Inside a paren or looking at it, lisp knows what to do. Say * is the point. The inconsistency I find is that C-M-left will do very different things while at the end of different lines: A) from sklearn.cross_validation import KFold* --> *from sklearn.cross_validation import KFold B) n = len(train.y)* --> n = len*(train.y) I think the intention is to nav at the "statement/block level" when the point is at the end of the line. The difference of behaviour between A and B can't be reconciled at any level: sexp, list, statement, block. My expectation would be: B') n = len(train.y)* --> *n = len(train.y) B'') n = len(train.y*) --> n = len(train.*y) Notice that this is even more conspicuous at the end of a block: C) for x in range(0, 10): x = 2 print("hello")* --> for x in range(0, 10): x = 2 print*("hello") D) for x in range(0, 10): print("hello") x = 2* --> *for x in range(0, 10): print("hello") x = 2 I vote for removing the (syntax-after (1- (point)) special case as IMO it only adds confussion to the already complex nav rules. Cheers -- Carlos ------------=_1428889503-748-1--