GNU bug report logs - #63959
python-mode does not keep indentation in square brackets []

Previous Next

Package: emacs;

Reported by: Konstantin Kharlamov <hi-angel <at> yandex.ru>

Date: Thu, 8 Jun 2023 09:40:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #31 received at 63959 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: kobarity <kobarity <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Konstantin Kharlamov <hi-angel <at> yandex.ru>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 63959 <at> debbugs.gnu.org
Subject: Re: bug#63959: python-mode does not keep indentation in square
 brackets []
Date: Wed, 28 Jun 2023 08:58:20 +0200
Il 24.06.23 14:37, kobarity ha scritto:
> Andreas Röhler wrote:
>>>> However, it may happen that the previous line is indented for the
>>>> inner paren as in the ERT `python-indent-inside-paren-2':
>>>>
>>>> data = {'key': {
>>>>       'objlist': [
>>>>           {'pk': 1,
>>>>            'name': 'first'},
>>>>           {'pk': 2,
>>>>            'name': 'second'}
>>>>       ]
>>>> }}
>>>>
>>>> The line "{'pk': 2," is considered as the continuation line, but it
>>>> should not respect the indentation of the PREVIOUS line "'name':
>>>> 'first'},".  So skipping such lines with inner parens were needed.
>>>> It searches backward for the line which starts with the item of the
>>>> same opening paren as the target line.
>>>>
>>>> In the case of the above example, if the target line is "{'pk': 2,",
>>>> its opening paren is "[" in the line "'objlist': [".  It first checks
>>>> the previous line "'name': 'first'},", but its opening paren is "{" in
>>>> "{'pk': 1,".  So this line is skipped.  Next, it checks the line
>>>> "{'pk': 1," and its opening paren is "[" in the line "'objlist': [",
>>>> which is same as the target line.  So the target line's indentation
>>>> will be as same as the line "{'pk': 1,".
>>>>
>>>> It would be helpful if you could try this patch.
>>> Thank you, tested, works for me!
>>>
>>>> Does anyone think we should have a customize variable that switches
>>>> between the traditional behavior of ignoring the indentation of the
>>>> previous line and this new behavior?
>>> I doubt it's useful. It is in general how indentation works in many modes, and I
>>> don't think there ever been a variable to disable that. Stefan Monnier in
>>> particular has a paper called "SMIE: weakness is power", where such indentation
>>> is shortly discussed.
>>>
>>>
>>> IMO the question of previous lines indentation isn't raised here, as a more specific rule applies: inside a non-empty list
>>> indent with its first element. Whereas if list starts empty, as with "[" here, next indents as that line plus offset.
> Let me explain it again.  I added the line numbers.
>
> 1: data = {'key': {
> 2:     'objlist': [
> 3:         {'pk': 1,
> 4:          'name': 'first'},
> 5:         {'pk': 2,
> 6:          'name': 'second'}
> 7:     ]
> 8: }}
>
> I think you are saying that the third line will be indented with an
> additional offset to the second line, am I correct?  If so, I totally
> agree with you.  This behavior has not changed with my patch.
>
> What I wanted to say in the previous mail is that the fifth line
> should align with the third line, not the fourth line.
>
> As for such standard indentation, my patch does not change the
> behavior.
>
> However, if the user intentionally changed the indentation of the
> third line, the current Python mode would indent the fourth and
> subsequent lines as follows:
>
> 1: data = {'key': {
> 2:     'objlist': [
> 3:             {'pk': 1,  # Intentionally changed
> 4:              'name': 'first'},
> 5:         {'pk': 2,
> 6:          'name': 'second'}
> 7:     ]
> 8: }}
>
> After applying my patch, it is indented as follows:
>
> 1: data = {'key': {
> 2:     'objlist': [
> 3:             {'pk': 1,  # Intentionally changed
> 4:              'name': 'first'},
> 5:             {'pk': 2,
> 6:              'name': 'second'}
> 7:     ]
> 8: }}


Thanks for your explanation, which makes me better understand your 
endeavour. A question remains: is this new feature worth that possibly 
raise of complexity? Your patch provides a higher degree of freedom 
while keeping regularity  - which is a pro.





This bug report was last modified 2 years and 11 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.