Subject: bug#28475: 25.3; python double-indents multi-line function argument blocks

From: Ross Donaldson <[email-masked]>
Date: Sun, 24 Sep 2017 16:25:48 +0000

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  <[email-masked]>

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 <
[email-masked]> wrote:

> Ross Donaldson <[email-masked]> 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.
>