GNU bug report logs -
#70617
30.0.50; python-indent-shift-right indents left when line is whitespace
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70617 in the body.
You can then email your comments to 70617 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70617
; Package
emacs
.
(Sat, 27 Apr 2024 23:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Patrick Poitras <patrick.f.poitras <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 27 Apr 2024 23:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all.
I've noticed this weird behavior of python-indent-shift-right.
Let's say I have a block of code. The "|" character represents my cursor
In a python file, I write
if True:
|
(... file contents continue)
and then call python-indent-shift-right on an empty line. It does nothing.
If the second line has any amount of spaces, the whitespace is entirely
deleted.
Given that Python's whitespace is syntactically significant, the expected
behavior should be to add an indent to an empty line, or to prepend 4
characters (or 8, given user choice) to the empty line if it has
whitespace. From a cursory glance, I think we're running into some behavior
of indent-rigidly that tries to prevent the addition of superfluous white
space following an indented block of code. I assume this would be
potentially desirable for languages with non-significant whitespace, but in
the case of the python-specific function, the resulting behavior defies
both the function name and description.
----- System information -----
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.41, cairo version 1.18.0) of 2024-04-27 built on
localhost.localdomain
Windowing system distributor 'The X.Org Foundation', version 11.0.12101012
System Description: openSUSE Tumbleweed
Configured using:
'configure --with-x --with-xpm --with-jpeg --with-tiff --with-png
--with-rsvg --with-dbus --with-xft --with-tree-sitter
--with-x-toolkit=gtk3 --with-native-compilation=aot --with-cairo
--with-libotf --with-modules --without-sound
--enable-link-time-optimization --with-json
SYS=--build=x86_64-suse-linux 'CFLAGS=-flto -O3 -march=native
-mtune=native''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBSYSTEMD MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
SECCOMP THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.utf8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
Major mode: Python
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
minibuffer-regexp-mode: t
line-number-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 time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-seq compile
text-property-search comp-run comp-common python rx project byte-opt gv
bytecomp byte-compile compat pcase treesit comint ansi-osc ring
cl-loaddefs cl-lib ansi-color 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 touch-screen 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 gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)
Memory information:
((conses 16 116911 12528) (symbols 48 7663 0) (strings 32 37654 2057)
(string-bytes 1 1726924) (vectors 16 21902)
(vector-slots 8 237509 8385) (floats 8 49 13) (intervals 56 419 0)
(buffers 992 13))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70617
; Package
emacs
.
(Mon, 29 Apr 2024 12:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 70617 <at> debbugs.gnu.org (full text, mbox):
> From: Patrick Poitras <patrick.f.poitras <at> gmail.com>
> Date: Sat, 27 Apr 2024 16:16:46 -0700
>
> Hi all.
>
> I've noticed this weird behavior of python-indent-shift-right.
>
> Let's say I have a block of code. The "|" character represents my cursor
>
> In a python file, I write
>
> if True:
> |
>
> (... file contents continue)
>
> and then call python-indent-shift-right on an empty line. It does nothing. If the second line has any amount of
> spaces, the whitespace is entirely deleted.
>
> Given that Python's whitespace is syntactically significant, the expected behavior should be to add an indent
> to an empty line, or to prepend 4 characters (or 8, given user choice) to the empty line if it has whitespace.
> From a cursory glance, I think we're running into some behavior of indent-rigidly that tries to prevent the
> addition of superfluous white space following an indented block of code. I assume this would be potentially
> desirable for languages with non-significant whitespace, but in the case of the python-specific function, the
> resulting behavior defies both the function name and description.
Any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70617
; Package
emacs
.
(Tue, 30 Apr 2024 07:28:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 70617 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>
> > From: Patrick Poitras <patrick.f.poitras <at> gmail.com>
> > Date: Sat, 27 Apr 2024 16:16:46 -0700
> >
> > Hi all.
> >
> > I've noticed this weird behavior of python-indent-shift-right.
> >
> > Let's say I have a block of code. The "|" character represents my cursor
> >
> > In a python file, I write
> >
> > if True:
> > |
> >
> > (... file contents continue)
> >
> > and then call python-indent-shift-right on an empty line. It does nothing. If the second line has any amount of
> > spaces, the whitespace is entirely deleted.
> >
> > Given that Python's whitespace is syntactically significant, the expected behavior should be to add an indent
> > to an empty line, or to prepend 4 characters (or 8, given user choice) to the empty line if it has whitespace.
> > From a cursory glance, I think we're running into some behavior of indent-rigidly that tries to prevent the
> > addition of superfluous white space following an indented block of code. I assume this would be potentially
> > desirable for languages with non-significant whitespace, but in the case of the python-specific function, the
> > resulting behavior defies both the function name and description.
>
> Any comments?
Hi Patrick,
I believe this behavior is intended to avoid adding extra whitespaces
when processing a region containing blank lines. There may be an
approach to change to indent even a blank line as a special case when
the region is not active, but I personally think that Enter or TAB
indentation is sufficient in such cases.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70617
; Package
emacs
.
(Thu, 09 May 2024 07:41:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 70617 <at> debbugs.gnu.org (full text, mbox):
tags 70617 wontfix
close 70617
thanks
> Date: Tue, 30 Apr 2024 16:26:13 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: 70617 <at> debbugs.gnu.org
>
> Eli Zaretskii wrote:
> >
> > > From: Patrick Poitras <patrick.f.poitras <at> gmail.com>
> > > Date: Sat, 27 Apr 2024 16:16:46 -0700
> > >
> > > Hi all.
> > >
> > > I've noticed this weird behavior of python-indent-shift-right.
> > >
> > > Let's say I have a block of code. The "|" character represents my cursor
> > >
> > > In a python file, I write
> > >
> > > if True:
> > > |
> > >
> > > (... file contents continue)
> > >
> > > and then call python-indent-shift-right on an empty line. It does nothing. If the second line has any amount of
> > > spaces, the whitespace is entirely deleted.
> > >
> > > Given that Python's whitespace is syntactically significant, the expected behavior should be to add an indent
> > > to an empty line, or to prepend 4 characters (or 8, given user choice) to the empty line if it has whitespace.
> > > From a cursory glance, I think we're running into some behavior of indent-rigidly that tries to prevent the
> > > addition of superfluous white space following an indented block of code. I assume this would be potentially
> > > desirable for languages with non-significant whitespace, but in the case of the python-specific function, the
> > > resulting behavior defies both the function name and description.
> >
> > Any comments?
>
> Hi Patrick,
>
> I believe this behavior is intended to avoid adding extra whitespaces
> when processing a region containing blank lines. There may be an
> approach to change to indent even a blank line as a special case when
> the region is not active, but I personally think that Enter or TAB
> indentation is sufficient in such cases.
No further comments, so I'm now closing this bug as wontfix.
Thanks.
Added tag(s) wontfix.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Thu, 09 May 2024 07:41:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
70617 <at> debbugs.gnu.org and Patrick Poitras <patrick.f.poitras <at> gmail.com>
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Thu, 09 May 2024 07:41:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 06 Jun 2024 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.