unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Pierre Mercatoris <mercatorispierre@gmail.com>
To: kobarity <kobarity@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Augusto Stoffel <arstoffel@gmail.com>,
	60142@debbugs.gnu.org
Subject: bug#60142: 28.1; python.el Incorrect region when python-shell-send-region from indented code
Date: Fri, 30 Dec 2022 14:14:58 +0100	[thread overview]
Message-ID: <CAK4ZG+4ARySAO=z2wzrS2yxXCqKgqpnNXDOA_Ov5vg17Lisd=Q@mail.gmail.com> (raw)
In-Reply-To: <eke7v8m3xz2c.wl-kobarity@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

Hello and sorry for the late reply..

Excuse my ignorance, but how would I need to go about to apply those
changes to test them?

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.

I hope I could explain myself better.

Thank you all for your interest in the matter.

On Thu, Dec 22, 2022 at 4:01 PM kobarity <kobarity@gmail.com> wrote:

> Augusto Stoffel wrote:
> > On Sun, 18 Dec 2022 at 12:39, Eli Zaretskii wrote:
> > >> If I select the `a` or `a = "test"` it will correctly send it to the
> > >> console, however it won't echo the evaluation of the statement.
> >
> > I can at least explain why this happens and is expected.
> >
> > An evaluation result is printed only if you send a bunch of statements,
> > the last of which is an expression.  OTOH, since whitespace is
> > significant in Python, if you evaluate anything that's not a "toplevel
> > form" it gets wrapper in a `if True:` statement, so the actually
> > evaluated code is not a simple expression anymore.
> >
> > It seems hard to work around this limitation.
>
> Sorry for the late reply.
>
> As Augusto explained, `if True:` is added to the indented region.
> This behavior is documented in `python-shell-buffer-substring'. Maybe
> it's better to add a reference to `python-shell-buffer-substring' in
> the docstring of `python-shell-send-region'.
>
> What I'm trying to do is to improve the behavior in some use cases.
> Specifically, there is no need to add `if True:` if the region
> consists of a single statement such as `a` or `a = "test"`.  Removing
> leading spaces should be enough to avoid an indentation error even if
> the single statement spans multiple lines.
>
> The corner case is the following use case.
>
> #+begin_src python
> if True:
>     s = """
>     a = 1
>     b = 2
> """
> #+end_src
>
> Let's assume we want to send the lines "a = 1" and "b = 1" only.
> Although they are part of a single statement (multiline string), `if
> True:` should be added to avoid an indentation error.  In other words,
> they should not be considered as a single statement.  To address such
> situation, the single statement check should be done after calling
> `narrow-to-region'.
>
> Attached is a patch to achieve this.  I appreciate your comments.
>
> Thanks,
>

[-- Attachment #2: Type: text/html, Size: 3540 bytes --]

  reply	other threads:[~2022-12-30 13:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 22:54 bug#60142: 28.1; python.el Incorrect region when python-shell-send-region from indented code pmercatoris
2022-12-18 10:39 ` Eli Zaretskii
2022-12-18 15:04   ` Pierre Mercatoris
2022-12-18 22:25     ` kobarity
2022-12-19  3:28       ` Eli Zaretskii
2022-12-19 10:25   ` Augusto Stoffel
2022-12-22 15:01     ` kobarity
2022-12-30 13:14       ` Pierre Mercatoris [this message]
2022-12-30 15:33         ` kobarity
2022-12-30 16:36           ` Pierre Mercatoris
2022-12-31  7:23             ` kobarity
2022-12-31  8:17               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK4ZG+4ARySAO=z2wzrS2yxXCqKgqpnNXDOA_Ov5vg17Lisd=Q@mail.gmail.com' \
    --to=mercatorispierre@gmail.com \
    --cc=60142@debbugs.gnu.org \
    --cc=arstoffel@gmail.com \
    --cc=eliz@gnu.org \
    --cc=kobarity@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).