GNU bug report logs - #28475
25.3; python double-indents multi-line function argument blocks

Previous Next

Package: emacs;

Reported by: Ross Donaldson <gastove <at> gmail.com>

Date: Sat, 16 Sep 2017 19:07:02 UTC

Severity: normal

Tags: fixed

Found in version 25.3

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ross Donaldson <gastove <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28475 <at> debbugs.gnu.org
Subject: bug#28475: 25.3; python double-indents multi-line function argument blocks
Date: Sun, 24 Sep 2017 16:25:48 +0000
[Message part 1 (text/plain, inline)]
First: apologies for the whitespace cleanup, but yes, you correctly figured
out what the bug report was intended to be. Thanks!

I was thrown off by the `prog-FOO` commands because of this message in the
ChangeLog:

```
2016-03-27  Dmitry Gutov  <dgutov <at> yandex.ru>

Remove prog-indentation-context

* lisp/progmodes/prog-mode.el: (prog-indentation-context)
(prog-first-column, prog-widen): Remove, as discussed in
http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01425.html.
```

But I see you are correct, and only `prog-indentation-context` was removed.

I haven't assigned copyright to Emacs yet; I'd be happy to, and also, I
suspect this patch will be quite short. I'll send it over soon.

On Sun, Sep 24, 2017 at 5:26 AM Noam Postavsky <
npostavs <at> users.sourceforge.net> wrote:

> Ross Donaldson <gastove <at> gmail.com> writes:
>
> > python-mode double-indents the arguments to function definitions.
> >
> > To reproduce:
> > 1. emacs -Q
> > 2. Enter the following:
>
> It seems your email client dropped the whitespace, but I guess you meant
>
> # This is fine:
> def foo(arg):
>     print('hello')
>
> # This is indented double:
> def foo(
>         bar,
>         baz
> ):
>     print('hello')
>
> # It should be:
> def foo(
>     bar,
>     baz
> ):
>     print('hello')
>
> # Only seems to be true for `def`s so far, eg:
> baz = list(
>     'good'
> )
>
>
> > This is caused by the function `python-indent--calculate-indentation`,
> > line ~1023 of `python.el`. Frustratingly, the behavior is hardcoded,
> > and apparently intentional, as we see at the end of the function:
> >
> > ```
> > (`(,(or :inside-paren-newline-start-from-block) . ,start)
> > ;; Add two indentation levels to make the suite stand out.
> > (goto-char start)
> > (+ (current-indentation) (* python-indent-offset 2)))
> > ```
> >
> > This is problematic. Python's holy grail of style, PEP-8, does not
> > specify how this indentation should be done. However, many companies
> > which write python -- like my employer -- create internal style guides
> > to fill in gaps left by PEP-8. So far, in my career, they *all*
> > indicate a single indent to be appropriate in this context.
> >
> > I'd like to propose two solutions; I don't know which will suit best:
> >
> > 1. Stop doubling indentation
> > 2. Make the indent scaling integer a variable, so that this behavior can
> be changed.
>
> I think the latter will be best, in case some people want the current
> indentation still.
>
> > A final complication for me is that, at least on `master` of the
> > Github emacs-mirror (https://github.com/emacs-mirror/emacs), this
> > function still uses `prog-widen` and `prog-first-column`, which have
> > been removed from emacs. I'm not sure how to correctly patch this
> > function to remove them.
>
> I think it's rather that `prog-widen' and `prog-first-column' have been
> *added* to Emacs.
>
> > So! With a little guidance on `prog-widen`/`prog-first-column`, I'm
> > happy to create and submit a patch, or I can leave this in y'all's
> > capable hands.
>
> If you can build from the git checkout write your patch against the
> emacs-26 branch then you should be able to use the prog-FOO functions.
> Otherwise, just write it against 25.3, it should be easy enough to
> update the patch afterwards, if needed.
>
> Have you assigned copyright to Emacs?  If the patch ends up more than
> about 15 lines we won't be able to accept it until you do.  I guess just
> adding and using the new custom variable should fit within that limit
> though.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 7 years and 140 days ago.

Previous Next


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