bug#72750: 29.3; indent-region changes semantics of python code

bug#72750: 29.3; indent-region changes semantics of python code

[Michael Arndt via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

I have a problem when indenting python files. There seems to be a case
when using indent-region changes the semantics of the python code. When
there is no blank line after an if-statement, the next line becomes part
of the if statement.

The problem can be reproduced by the following steps:

1. Start emacs -Q
2. Create a python file with the following contents:

if False:
      print("output1")
print("output2")

3. Use M-x mark-whole-buffer
4. Use M-x indent-region
5. The file contents change into:

if False:
      print("output1")
      print("output2")

The problem can be avoided by adding a blank line after the if statement.
Because I use a custom indentation function that calls (indent-region
(point-min) (point-max)) this can happen pretty quickly. Is this a
limitation of python-indent-region?

Greetings
Michael


In GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.33,
cairo version 1.18.0) of 2024-04-02 built on titan
Repository revision: ae8f815613c2e072e92aa8fe7b4bcf2fdabc7408
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid

Configured using:
'configure CFLAGS=-O3 --with-json --with-native-compilation
--without-xinput2 --with-modules --prefix=/usr/local
--with-tree-sitter'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE
XIM XPM GTK2 ZLIB

Important settings:
value of $LC_TIME: de_DE.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 77191 7214)
(symbols 48 7170 0)
(strings 32 19723 1946)
(string-bytes 1 598864)
(vectors 16 15710)
(vector-slots 8 328515 15479)
(floats 8 39 46)
(intervals 56 242 0)
(buffers 984 12))

bug#72750: 29.3; indent-region changes semantics of python code

[Andreas Röhler]

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


Am 21.08.24 um 20:06 schrieb Michael Arndt via Bug reports for GNU 
Emacs, the Swiss army knife of text editors:
> Hi,
>
> I have a problem when indenting python files. There seems to be a case
> when using indent-region changes the semantics of the python code. When
> there is no blank line after an if-statement, the next line becomes part
> of the if statement.
>
> The problem can be reproduced by the following steps:
>
> 1. Start emacs -Q
> 2. Create a python file with the following contents:
>
> if False:
>      print("output1")
> print("output2")
>
> 3. Use M-x mark-whole-buffer
> 4. Use M-x indent-region
> 5. The file contents change into:
>
> if False:
>      print("output1")
>      print("output2")
>
> The problem can be avoided by adding a blank line after the if statement.
> Because I use a custom indentation function that calls (indent-region
> (point-min) (point-max)) this can happen pretty quickly. Is this a
> limitation of python-indent-region?
>
> Greetings
> Michael
>
>
Hi Michael,

I'm not maintaining the related code, just a comment:

as indent might by syntax at Python, there is not way for 
auto-formatting - unless you are happy with the outmost reasonable indent.

|Best,|

|Andreas
|

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

bug#72750: 29.3; indent-region changes semantics of python code

[Stefan Kangas]

Michael Arndt via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> I have a problem when indenting python files. There seems to be a case
> when using indent-region changes the semantics of the python code. When
> there is no blank line after an if-statement, the next line becomes part
> of the if statement.
>
> The problem can be reproduced by the following steps:
>
> 1. Start emacs -Q
> 2. Create a python file with the following contents:
>
> if False:
>       print("output1")
> print("output2")
>
> 3. Use M-x mark-whole-buffer
> 4. Use M-x indent-region
> 5. The file contents change into:
>
> if False:
>       print("output1")
>       print("output2")
>
> The problem can be avoided by adding a blank line after the if statement.
> Because I use a custom indentation function that calls (indent-region
> (point-min) (point-max)) this can happen pretty quickly. Is this a
> limitation of python-indent-region?

I'm not sure that I see a bug here.  I don't think one can generally
expect `indent-region` to be able to avoid changing semantics in a
language where indentation matters.

I'm copying in kobarity, in case he has any comments.

bug#72750: 29.3; indent-region changes semantics of python code

[kobarity]

Stefan Kangas wrote:
> Michael Arndt via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
> 
> > I have a problem when indenting python files. There seems to be a case
> > when using indent-region changes the semantics of the python code. When
> > there is no blank line after an if-statement, the next line becomes part
> > of the if statement.
> >
> > The problem can be reproduced by the following steps:
> >
> > 1. Start emacs -Q
> > 2. Create a python file with the following contents:
> >
> > if False:
> >       print("output1")
> > print("output2")
> >
> > 3. Use M-x mark-whole-buffer
> > 4. Use M-x indent-region
> > 5. The file contents change into:
> >
> > if False:
> >       print("output1")
> >       print("output2")
> >
> > The problem can be avoided by adding a blank line after the if statement.
> > Because I use a custom indentation function that calls (indent-region
> > (point-min) (point-max)) this can happen pretty quickly. Is this a
> > limitation of python-indent-region?
> 
> I'm not sure that I see a bug here.  I don't think one can generally
> expect `indent-region` to be able to avoid changing semantics in a
> language where indentation matters.

I agree.  Even though `python-indent-region' can be improved to some
extent, it seems to me that it is better to use an external tool like
"black" to preserve the semantics and format the entire buffer.

bug#72750: 29.3; indent-region changes semantics of python code

[Michael Arndt via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On 21.09.24 16:51, kobarity wrote:
> I agree.  Even though `python-indent-region' can be improved to some
> extent, it seems to me that it is better to use an external tool like
> "black" to preserve the semantics and format the entire buffer.
That's fine for me too. I will use something like `eglot-format' to 
format my python files instead. Thank you.

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

bug#72750: 29.3; indent-region changes semantics of python code

[Stefan Kangas]

tags 72750 + notabug wontfix
close 72750
thanks

Michael Arndt <michael@rndt.dev> writes:

> On 21.09.24 16:51, kobarity wrote:
>> I agree.  Even though `python-indent-region' can be improved to some
>> extent, it seems to me that it is better to use an external tool like
>> "black" to preserve the semantics and format the entire buffer.
> That's fine for me too. I will use something like `eglot-format' to
> format my python files instead. Thank you.

You could also try the package `blacken`:

    https://github.com/pythonic-emacs/blacken

I'm closing this bug report.