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

[Noam Postavsky <npostavs@users.sourceforge.net>]

Ross Donaldson <gastove@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.