From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: kobarity Newsgroups: gmane.emacs.bugs Subject: bug#60142: 28.1; python.el Incorrect region when python-shell-send-region from indented code Date: Sat, 31 Dec 2022 00:33:13 +0900 Message-ID: References: <83mt7lf12y.fsf@gnu.org> <87zgbjheqt.fsf@gmail.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/mixed; boundary="Multipart_Sat_Dec_31_00:33:10_2022-1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36085"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Cc: Eli Zaretskii , Augusto Stoffel , 60142@debbugs.gnu.org To: Pierre Mercatoris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 30 16:34:30 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pBHOv-0009GQ-P6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Dec 2022 16:34:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBHOW-0006jW-7D; Fri, 30 Dec 2022 10:34:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBHOV-0006iV-93 for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2022 10:34:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pBHOV-0008CT-10 for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2022 10:34:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pBHOU-0008H1-DK for bug-gnu-emacs@gnu.org; Fri, 30 Dec 2022 10:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: kobarity Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Dec 2022 15:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60142 X-GNU-PR-Package: emacs Original-Received: via spool by 60142-submit@debbugs.gnu.org id=B60142.167241442031777 (code B ref 60142); Fri, 30 Dec 2022 15:34:02 +0000 Original-Received: (at 60142) by debbugs.gnu.org; 30 Dec 2022 15:33:40 +0000 Original-Received: from localhost ([127.0.0.1]:35937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBHO7-0008GT-QL for submit@debbugs.gnu.org; Fri, 30 Dec 2022 10:33:40 -0500 Original-Received: from mail-pg1-f173.google.com ([209.85.215.173]:35603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBHO6-0008GG-At for 60142@debbugs.gnu.org; Fri, 30 Dec 2022 10:33:38 -0500 Original-Received: by mail-pg1-f173.google.com with SMTP id f3so14406507pgc.2 for <60142@debbugs.gnu.org>; Fri, 30 Dec 2022 07:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:references:in-reply-to:subject:cc:to:from :message-id:date:from:to:cc:subject:date:message-id:reply-to; bh=bN0LnKf5dPmG3lJzCEKiE5uLWGSsRPy/4ekuLVB95nw=; b=kxzsCTOLEoJddLJB04Tr61TBpN1dKTSSr7Osuaw3HpYRWPjYyvkaQ4iANv9aYJltVS 5ZFjNpuyG/c2OUNFcunLT8g9gu7cEqrOIQkKFw08ZJaz+uuCpnfXj2kQDoW506s1HeHB kmw0aK6XZ7wJD3wHCDM7ISwMJYHUQLjj/PvrzbaSlbcET63ctcV6ZOi9C5jH3r6GWo9t tGG8QPZrhJEZFY10m2j70e6li9j+t36qhiAJH6jGARqFcm7xklRk4iGagSGfFvye9vFW vlGFd1RGH3+FDSUPrKhH7f4hOtrL4TEeyQBrBZG/GrwK5uu7jxEQZ043MgNMOAx10YG4 VZmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:in-reply-to:subject:cc:to:from :message-id:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bN0LnKf5dPmG3lJzCEKiE5uLWGSsRPy/4ekuLVB95nw=; b=XvjVicNQ/EWKx5JHyqkhfIHzLgplByOU7v9g+fVREjqW6HB7ICMRIRSUbQgwCbCS9d 1AngBpTvPKdUeMY5RxtU57VrilB6UFn6MdgO1llT4pbJ10dlk5btJ8uRspR7YBU4a5Fx q97kOGafWGKTIOOrc7NcpmfSTb+Li4MHpG9z6YEPcv2Vp7SzBiBcDVVpcXpMxL9/5PhB W3deLbozUgzj7hS0pjlW7ndCoPFri2gjRG+LDbTtnsm3iWng3lvpl1LTDLTBiFTiVDB8 0ENlhXB2vT2n5YedBkQuuEpaJIaeKkRy9LD0F3YIEYHo9wAxvFamdLSzwlTiMTNWQ7Zy 5sSw== X-Gm-Message-State: AFqh2ko+lvuQAv/n8PB3Tid34pHeC/f3h7iX0LzcaWVpaK+LXSpcfMNi wtEuLo+UjgTXx5WwNZS+Pto= X-Google-Smtp-Source: AMrXdXtGUXfqxRNgiRBX8Sph+LzP7SxAjkDXIeE78Saa/7K2iJruFp5ildcOZt9qqc4J9C3vHxsqZQ== X-Received: by 2002:a05:6a00:1255:b0:576:b8e1:862b with SMTP id u21-20020a056a00125500b00576b8e1862bmr41242230pfi.14.1672414412275; Fri, 30 Dec 2022 07:33:32 -0800 (PST) Original-Received: from localhost (58x12x133x161.ap58.ftth.ucom.ne.jp. [58.12.133.161]) by smtp.gmail.com with ESMTPSA id x74-20020a62864d000000b0058217bbc6f5sm388860pfd.215.2022.12.30.07.33.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Dec 2022 07:33:31 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252132 Archived-At: --Multipart_Sat_Dec_31_00:33:10_2022-1 Content-Type: text/plain; charset=US-ASCII Hi, Pierre Mercatoris wrote: > Excuse my ignorance, but how would I need to go about to apply those changes > to test them? The patch in my previous mail is a diff to master branch of Emacs. I attached a patch to python.el of Emacs 28.1. It can be applied as follows: % patch python.el python.el.28.1.patch After starting Emacs, I recommend to do 'M-x load-file' and specify the patched python.el to avoid loading the old python.elc. > Furthermore, I am not sure the main issue I raised has been diluted. Basically > I was wondering why a region, which does not include any indentation (as it is > a fragment of a line), is sent to the repl results in indentation error if the > life the fragment comes from was indented. In the case Kobarty described > above, he is mentioning sending the whole line to the repl, in which case it > can be debated how to deal with indentation. However, my issue is that > equivalent regions sent to the repl without any indentation within them > results in different behaviours depending on where those regions (fragments of > line) come from. My explanation was probably misleading. I'm not saying that the whole line should be sent to the REPL. My point was that if the content sent to the REPL is one statement, there is no need to add `if True:`. Please note that a "statement" in python.el is a logical unit based on Python syntax and differs from physical lines. A statement can be part of a physical line, and it can also spans multiple physical lines. As Augusto pointed out, current Emacs python.el adds `if True:` if the lines of the region was originally indented. For example, let's consider the following code. #+begin_src python def func(): a = 1 b = 2 #+end_src If we set the region to "a = 1" and call `python-shell-send-region', the following code will be sent to the REPL. #+begin_src python if True: a = 1 #+end_src Even if the region is set to only "a", the following code will be sent. #+begin_src python if True: a #+end_src Adding `if True:` is reasonable if the indented region spans multiple lines. For example, if the region is "a = 1\n b = 2", the following code will be sent. #+begin_src python if True: a = 1 b = 2 #+end_src If the region "a = 1\n b = 2" or " a = 1\n b = 2" is sent as is, an indentation error will occur. I think current `python-shell-send-region' focuses on sending a region of multiple lines and does not take into account sending part of a line. As I mentioned above, my patch is intended to improve this behavior. If the region is "a = 1", or even " a = 1", the following code will be sent because this is a single statement. #+begin_src python a = 1 #+end_src I think this behavior is what you expected. Please note that the above explanation is a bit simplified. The actual contents `python-shell-send-region' sends includes a coding cookie and empty lines. Please see docstring of `python-shell-buffer-substring' for more details. I hope this clarifies things. Regards, --Multipart_Sat_Dec_31_00:33:10_2022-1 Content-Type: application/octet-stream; type=patch; name="python.el.28.1.patch" Content-Disposition: attachment; filename="python.el.28.1.patch" Content-Transfer-Encoding: 7bit --- python.el.orig 2022-12-30 23:17:47.490936027 +0900 +++ python.el 2022-12-30 23:19:25.555944407 +0900 @@ -3262,19 +3262,35 @@ appending extra empty lines so tracebacks are correct. 3. When the region sent is a substring of the current buffer, a coding cookie is added. - 4. Wraps indented regions under an \"if True:\" block so the - interpreter evaluates them correctly." - (let* ((start (save-excursion - ;; If we're at the start of the expression, and - ;; there's just blank space ahead of it, then expand - ;; the region to include the start of the line. - ;; This makes things work better with the rest of - ;; the data we're sending over. + 4. When the region consists of a single statement, leading + whitespaces will be removed. Otherwise, wraps indented + regions under an \"if True:\" block so the interpreter + evaluates them correctly." + (let* ((single-p (save-restriction + (narrow-to-region start end) + (= (progn + (goto-char start) + (python-nav-beginning-of-statement)) + (progn + (goto-char end) + (python-nav-beginning-of-statement))))) + (start (save-excursion + ;; If we're at the start of the expression, and if + ;; the region consists of a single statement, then + ;; remove leading whitespaces, else if there's just + ;; blank space ahead of it, then expand the region + ;; to include the start of the line. This makes + ;; things work better with the rest of the data + ;; we're sending over. (goto-char start) - (if (string-blank-p - (buffer-substring (line-beginning-position) start)) - (line-beginning-position) - start))) + (if single-p + (progn + (skip-chars-forward "[:space:]" end) + (point)) + (if (string-blank-p + (buffer-substring (line-beginning-position) start)) + (line-beginning-position) + start)))) (substring (buffer-substring-no-properties start end)) (starts-at-point-min-p (save-restriction (widen) @@ -3297,7 +3313,7 @@ (insert fillstr)) (insert substring) (goto-char (point-min)) - (when (not toplevel-p) + (when (and (not single-p) (not toplevel-p)) (insert "if True:") (delete-region (point) (line-end-position))) (when nomain @@ -3339,7 +3355,8 @@ When called interactively SEND-MAIN defaults to nil, unless it's called with prefix argument. When optional argument MSG is non-nil, forces display of a user-friendly message if there's no -process running; defaults to t when called interactively." +process running; defaults to t when called interactively. The +substring to be sent is retrieved using `python-shell-buffer-substring'." (interactive (list (region-beginning) (region-end) current-prefix-arg t)) (let* ((string (python-shell-buffer-substring start end (not send-main) --Multipart_Sat_Dec_31_00:33:10_2022-1--