This looks good to me -- let's wait a week to see if there's any activity on the thread you linked, but this should be a quick merge based on the state of things.

I do notice the el file itself doesn't have any indication of its license, so some kind of license identifier would probably be good to add while bringing this package up to snuff. And thanks. :)

Thanks for checking on this:
Added SPDX license identifier, updated URL and some other minor improvements.

I plan some other changes such as supporting formatting a region of text and optionally formatting depending on an autopep8 entry in pyproject.xml, but that's not essential for basic working functionality.

Since the review you made this change: https://github.com/ideasman42/emacs-py-autopep8/commit/089ecfa256cd6aa2929de328af067af9d06214e0.

IMO it is a mistake that you indent lisp differently from everybody else. I brought that up when you proposed your indentation package. We added it anyway so that you can indent as you wish and contributors to your packages can automatically indent as intended by the maintainer without too much pain.

But when taking over someone else's package, then I think you should really stick to the default indentation rules.

It's particularly important to stick to the rules in this case: How can a potential user trust a package that has the purpose to indent python as python is intended to be indented if it is implemented using lisp that is indented as if it were python?

Since the review you made this change: ideasman42/emacs-py-autopep8@089ecfa.

IMO it is a mistake that you indent lisp differently from everybody else.
I brought that up when you proposed your indentation package. We added it anyway so that you can indent as you wish and contributors to your packages can automatically indent as intended by the maintainer without too much pain.

Not sure which package you're referring to, my auto-formatting package isn't included in melpa.

But when taking over someone else's package, then I think you should really stick to the default indentation rules.

I'd agree with your perspective if developers were actively contributing to it, however this project (as far as I can tell) has been abandoned since 2016, not being updated doesn't necessarily mean "dead" - in this case it had some fairly significant flaws that went unaddressed. It's practically rewritten & while I could upload a new package - it doesn't seem useful to have two autopep8 auto-formatting packages in melpa - as it's simple enough to match the existing calls.

Since I intend to update and support it, I think it's reasonable to be able to define the code-style, while it's a bit different, I don't consider it hostile to other developers and have had significant contributions from community members in the past - with the advantage I can reformat their patches even if they don't use the auto-formatter.

It's particularly important to stick to the rules in this case: How can a potential user trust a package that has the purpose to indent python as python is intended to be indented if it is implemented using lisp that is indented as if it were python?

I don't see having fixed indentation per nesting as being especially pythonic, it's mostly to be predictable (indentation depth reflects nesting) and generally avoiding right-shift (something I've found in practically all other lisp auto-formatters that tend to indent heavily and cause a lot of line wrapping).

Not sure which package you're referring to, my auto-formatting package isn't included in melpa.

I guess I remembered that wrong and I voiced my discomfort when we added a package that used your auto-formatting package.

But when taking over someone else's package, then I think you should really stick to the default indentation rules.

I'd agree with your perspective if developers were actively contributing to it, however this project (as far as I can tell) has been abandoned since 2016, not being updated doesn't necessarily mean "dead" - in this case it had some fairly significant flaws that went unaddressed. It's practically rewritten & while I could upload a new package - it doesn't seem useful to have two autopep8 auto-formatting packages in melpa - as it's simple enough to match the existing calls.

I am okay with it then. Obviously not thrilled, but writing a new package would we a waste.

I don't see having fixed indentation per nesting as being especially pythonic, it's mostly to be predictable (indentation depth reflects nesting) and generally avoiding right-shift (something I've found in practically all other lisp auto-formatters that tend to indent heavily and cause a lot of line wrapping).

I just picked python because ... well obvious reasons. I don't use lisp (or other) auto-formatters but am quite happy with the results of doing it manually. Sometimes the nesting gets surprisingly deep but in my experience it is almost always possible to get a reasonable result while staying below 80 characters per line. One slightly ugly trick I am a little more often forced to use than I would hope, is to put the first argument right below the function (and then sometimes all the other arguments on the same line). But that is less of a Lisp problem than it is a elisp-has-no-namespaces-so-everything-gets-a-bit-long problem.

But back on topic: I am okay with this and won't protest anymore.

Thread's been quiet for over a week, I think this is good to merge. I think I also remember making a comment about the formatting choices. :)

Since I'm running my workflow here anyway here are a couple lints that get picked up:

• py-autopep8.el#L149: It's safer to sharp-quote function names; use #'
• py-autopep8.el#L153: It's safer to sharp-quote function names; use #'
• py-autopep8.el#L58: No format required; user-error takes an f-string

Thanks @riscy addressed issues and added support for formatting the selection & conditionally formatting based on the existence of an autopep8 configuration entry.

Note, elisp-autofmt now follows a more standard emacs formatting style which this package now uses.