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" <edream...@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 > [pep8-based] nagging about formatting. > You will save time and mental energy for more important matters. > > Because of the problems with black discussed above, I'll look into > adding black's line-breaking algorithm to Leo's beautify commands. > The ultimate goal would be to adjust all lines as we type. > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/20190728171458.0eaaf106%40lakeview.
