Fix for Issue #48: Changed the black executable from string to list … - #59
Fix for Issue #48: Changed the black executable from string to list …#59sbroberg wants to merge 1 commit into
Conversation
Sorry, something went wrong.
…string to a list to allow 'python -m black' to be used instead of just 'black' for the executable name. This is because black as a standalong executable is not something that is typically supported on windows, but the python module invocation always works, and the zombie processes that were using up file handles for Issue 48 was due to the make-process function failing when it couldn't find a black executable. Changing blacken-executable to the list fixes this problem (assuming the black module is installed).
|
|
||
| (defcustom blacken-executable-list '(blacken-executable) | ||
| "Command (with extra arguments) to invoke black" | ||
| :type '(repeat string)) |
There was a problem hiding this comment.
We can turn this into an empty list and then concatenate the list with the executable below.
Sorry, something went wrong.
There was a problem hiding this comment.
I did it this way because "python -m black" is equivalent to "black" in that both invoke black with no parameters. Otherwise, to configure it as you suggest would require you to set blacken-executable to "python" and blacken-executable-list (or whatever we'd rename it to) to ("-m" "black"), which seems sort of weird to me.
Alternatively, we can leave "black" in blacken-executable alone and have this empty list precede it, like so:
:command `(,@blacken-python-startup-list ,blacken-executable ,@(blacken-call-args))
and have the user-visible config option the string blacken-python-command-for-invocation. If this string is not nil, we would set blacken-python-startup-list to (blacken-python-command-for-invocation "-m").
This would make it more clear to users what the purpose of this setting is for, even if the implementation is more fiddly. It also has the advantage of leaving people's config intact if for some reason they had previously overridden blacken-executable (although my implementation does as well).
Sorry, something went wrong.
… to allow 'python -m black' to be used instead of just 'black' for the executable name. This is because black as a standalong executable is not something that is typically supported on windows, but the python module invocation always works, and the zombie processes that were using up file handles for Issue 48 was due to the make-process function failing when it couldn't find a black executable. Changing blacken-executable to the list fixes this problem (assuming the black module is installed).