From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Branham Newsgroups: gmane.emacs.bugs Subject: bug#29608: python.el movement functions Date: Fri, 08 Dec 2017 15:37:15 -0600 Message-ID: <87mv2syk8k.fsf@gmail.com> References: <87vahigsa9.fsf@gmail.com> <5refo5xfvn.fsf@fencepost.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512769113 31515 195.159.176.226 (8 Dec 2017 21:38:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 8 Dec 2017 21:38:33 +0000 (UTC) User-Agent: mu4e 0.9.18; emacs 25.3.1 Cc: 29608@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 08 22:38:28 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNQLk-00084y-52 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Dec 2017 22:38:28 +0100 Original-Received: from localhost ([::1]:39124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNQLr-00041O-Dg for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Dec 2017 16:38:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNQLO-00031O-3v for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 16:38:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNQLL-0004UV-0e for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 16:38:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44272) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eNQLK-0004UJ-UC for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 16:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eNQLK-0007iA-Fc for bug-gnu-emacs@gnu.org; Fri, 08 Dec 2017 16:38:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alex Branham Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Dec 2017 21:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29608 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29608-submit@debbugs.gnu.org id=B29608.151276904529600 (code B ref 29608); Fri, 08 Dec 2017 21:38:02 +0000 Original-Received: (at 29608) by debbugs.gnu.org; 8 Dec 2017 21:37:25 +0000 Original-Received: from localhost ([127.0.0.1]:52953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNQKj-0007hM-Ca for submit@debbugs.gnu.org; Fri, 08 Dec 2017 16:37:25 -0500 Original-Received: from mail-oi0-f46.google.com ([209.85.218.46]:41618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNQKh-0007h8-Qd for 29608@debbugs.gnu.org; Fri, 08 Dec 2017 16:37:24 -0500 Original-Received: by mail-oi0-f46.google.com with SMTP id t78so8060434oie.8 for <29608@debbugs.gnu.org>; Fri, 08 Dec 2017 13:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:user-agent:in-reply-to:date :message-id:mime-version; bh=KFBAOCn9cdSP3dDRPua3r46Rh4Ajkv+Pp+3kRcOLoCQ=; b=j7qibHyoVCaMiAa5Gu16TcWgZAgeivMD5m7fIpXZ48LJiDKhB6/rdCfCRiGNHOBU9L SL0vi7HhmQbrG215QbAaopozudeugElPh37nMLG+QV6a6UTvFQKB2nrdM6HAiBjg8WXW i33ztMqutm8hTfLUGYUVOIADszeKpcEuM5hdiWcxl7ciPm95xyq1nQmgm0dpznCk5cUH Xnn1iKeVWPD9/0KS8WhQyPw8qbXjBXBmMgVn1cKvoNUB412nmNVvUpFarpCJX99muDDS +cgzAeEK86csQnUTi+hBAlYly6iV+iYmEkhrH6bm1mfTGkelhgZUWz4hjpvg4QS8MpEC C3DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:user-agent :in-reply-to:date:message-id:mime-version; bh=KFBAOCn9cdSP3dDRPua3r46Rh4Ajkv+Pp+3kRcOLoCQ=; b=f5d4O/1GL8mxMhkfO1Xsc2TJzp4E6f9oFJOjlaKmcmgGGLa3XVgOGZThRz93wTxXlR Uzv6NbGS7k2Kn0M26VdA0Cb+emRyDT2vfhsq7g8HNO0JCG9zuf8JZlsft905zQezR0wH E+MWKLTcFGmk0EENfhzprtQ/yEPZob9A6WYvDwcL47KrI4HYd+43/I2u3idnjHyOzfLy 7N7jCVcd1gX5HI7zwXQqCUBeDa47a3xY2urAwo7JlZhIWfZ+1EPRe5d8NMmrwItCIAit ob/XYhmH3PwRiIZvvx9SwK2eiXr324F4r75AhT2kOCk7WlQB3IamkjXT9tcsX/t4ZaJV dpIA== X-Gm-Message-State: AJaThX5V97vyiRXb5DG4q0uZsGDLmNFHAV8VPRBEbPziTIU5PXfEIQnY kIcy1Gjtp3bsOiJ9SGM0nHGTeOV8 X-Google-Smtp-Source: AGs4zMYRJzKYPUXMsCM9OHCg3TTWwl9vTS3pcp8h6mEPWdvSy76OTFpkPXRLCjdecZg85jqUoizJuA== X-Received: by 10.202.74.88 with SMTP id x85mr26618044oia.215.1512769037645; Fri, 08 Dec 2017 13:37:17 -0800 (PST) Original-Received: from mars (nat-128-62-59-183.public.utexas.edu. [128.62.59.183]) by smtp.gmail.com with ESMTPSA id n130sm3680884oia.12.2017.12.08.13.37.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Dec 2017 13:37:17 -0800 (PST) In-reply-to: <5refo5xfvn.fsf@fencepost.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:140839 Archived-At: On Fri 08 Dec 2017 at 17:56, Glenn Morris wrote: > Alex Branham wrote: > >> Python movement statements do not always result in the behavior I'd >> expect. Consider this python file (with (|) representing point): >> >> (|)for i in [1, 2, 3]: >> print(i) >> >> I'd expect M-x python-nav-forward-statement to result in >> >> for i in [1, 2, 3]: >> print(i) >> (|) >> >> but instead you wind up with >> >> for i in [1, 2, 3]: >> (|)print(i) > > The actual result seems reasonable to me? I'd argue that a "statement" should contain a whole logically valid statement, but I see your point. > >> and python-nav-forward-block (bound to M-e) is even worse. It results >> in point not moving at all: >> >> (|)for i in [1, 2, 3]: >> print(i) > > It seems that you disagree with python.el's definition of "statement" and > "block". Eg the block definition seems to be: > > (defconst python-rx-constituents > `((block-start . ,(rx symbol-start > (or "def" "class" "if" "elif" "else" "try" > "except" "finally" "for" "while" "with" > ;; Python 3.5+ PEP492 > (and "async" (+ space) > (or "def" "for" "with"))) > symbol-end)) Shouldn't python-nav-forward-block actually navigate forward, though? And if we're on the last block in the buffer, just leave point at the end? This might be off-topic, but what I'm trying to do is to write a function that I can bind so that C- acts like it does in ESS where you can continue to hit it and it will eventually evaluate everything in the buffer. Here's what I have so far: (defun python-shell-send-region-or-statement () "Send the current region to the inferior python process if there is an active one, otherwise the current line." (interactive) (if (use-region-p) (python-shell-send-region (region-beginning) (region-end)) (python-shell-send-statement))) (defun python-shell-send-statement () "Send the current line to the inferior python process for evaluation." (interactive) (save-excursion (let ((end (python-nav-end-of-statement)) (beginning (python-nav-beginning-of-statement))) (python-shell-send-region beginning end)))) (defun python-shell-send-region-or-statement-and-step () "Call `python-shell-send-region-or-statement' and then `python-nav-forward-statement'." (interactive) (python-shell-send-region-or-statement) (python-nav-forward-statement))