first of all, thanks for writing this package!
i used blacken.el
in the past, but i stopped using it recently since i think there are better options available to me… please allow me to explain. :)
a while ago i wrote black-macchiato to allow formatting of partial files using black
. (see also #11.)
to integrate black-macchiato
with emacs, i wrote black-macchiato.el, which currently lives as a private minimalistic emacs package inside my dotfiles.
as you can see, it looks rather trivial, thanks to reformatter.el, which is a great library. i have positive experiences using it: i recently published a json and jsonlines reformatter: jq-format.el, which, together with my related flycheck json-jq checker (included in flycheck), makes working with json and jsonlines files a breeze.
let's get back to python. what i want is: black integration for python editing in emacs, with buffer reformatting, partial formatting, an on save hook, and minimal configuration. in practice, i want an emacs package that:
- is based on
reformatter.el
- uses
black
for normal operations
- optionally uses
black-macchiato
for partial reformatting
- is available on melpa
- is actively maintained
- has documentation (could be a README) ;)
i really want to see this happen. compared to the current blacken.el
, the above will be simpler (by reusing third party libraries and tools), and it would also solve things like #11 properly.
now, i can see this going forward in a couple of ways:
-
port this package over to reformatter.el
and add the missing features. this will likely break backwards compatibility, e.g. different command names, configuration, maybe even the package name.
-
a ‘competing’ package doing exactly what i described above, and publish it on melpa. actually i considered doing this already, then stopped myself… and now i am writing this message instead.
i would be interested in your thoughts. i understand you may not be interested in my ideas/proposal, or you are too busy, and that is totally fine… which leads me to the following:
you could just say ‘go ahead and take over!’ and let me reimplement another emacs-python-black package, since i am actually willing to do all the work to make this happen. once i'm done, you could consider deprecating this package (or just leave it)... and you could sit back, relax, and use my package instead. :)
for reference, i successfully did a similar thing with my relatively widely used emacs-direnv project, which obsoleted multiple half-working earlier attempts to solve the same problem, projectile-direnv and direnv-el, in a friendly, non-competitive way; see here and here.
hope to hear from you!