I've been using black for quite a while. I agree it's probably not
fast enough to continuously reformat a file as you type, but that would
probably be annoying. I just have a "run black on file" shortcut
noremap <Leader>l mtgg!Gblack -S -q -l 79 -<CR>`t
that binds \l to run black, including setting a mark (t) and jumping
back to it when done.
Python mode in vim runs 2-3 checkers on save, one of which reports
PEP-8 violations, so I run it when I see that, or when I've typed
something in a lazy mess and want it cleaned up.
Cheers -Terry
On Sun, 28 Jul 2019 14:03:36 -0700 (PDT)
"Edward K. Ream" <
edre...@gmail.com> wrote:
> The black python formatter <
https://github.com/psf/black>is worthy of
> serious consideration. Its best feature is line wrapping
> <
https://github.com/psf/black#how-black-wraps-lines>, moderated by a
> maximum line length setting (code setting in the API and/or
> command-line arg).
>
> The "black" branch
> <
https://github.com/leo-editor/leo-editor/issues/1058> contains
> experimental code to reformat @file nodes using black. At present,
> the code only reports the diffs that would be produced if the code
> were actually changed.
>
> After playing with black for awhile (with various values of the line
> length setting), my reactions were:
>
> 1. This is pretty much how I break lines myself.
> 2. Why didn't anybody think about doing this before?
> 3. Leo's beautify commands should do something similar.
>
>
> *Problems with black*
>
> Leo's beautify commands are token oriented. In contrast, black's
> code is based on parse trees. Parse trees would seem like the
> industrial-strength way. Alas, black looks considerably times slower
> than Leo's beautify commands. Speed matters a lot if one is
> intending to "blacken" code on the fly. Otoh, I may be
> misunderstanding the underlying speed of black.
>
> One of my speed experiments was to blacken an entire file at once.
> This sidesteps problems with using Leonine syntax (@doc parts,
> section references, Leo directives) on a node-by-node basis. Alas,
> this experiment failed because *black thinks Leo's sentinel comments
> should have a space between the '#" and the '@'*. Yes, I could
> monkey-patch black's comment check to work around this, but it would
> be very ugly, and would probably difficult to do accurately in all
> situations.
>
> *Improving Leo's beautify commands*
>
> An alternative to using black itself would be to improve Leo's
> existing beautify commands so they follow black's line-breaking
> strategy. I believe this would be relatively straightforward. This
> would be a major departure for Leo's beautify commands. At present,
> these commands never insert or delete newlines. Still I plan to
> experiment with allowing the beautify commands to insert or delete
> newlines.
>
> *Summary*
>
> Black's line breaking algorithm is good enough to justify black's
> basic premise:
>
> [When using black], you agree to cede control over minutiae of
> hand-formatting.
> In return, *Black* gives you speed, determinism, and freedom from