Next steps re black and orange

[Edward K. Ream]

This posts discusses my plans for support for black and orange.

Remove all of Leo's black-related commands

They don't work, and can't be made to work reliably without support in black itself for Leo's syntax.  This is unlikely ever to happen.  I'll move the old code into Leo's attic, leo/doc/leoAttic.txt, so that it will be easily available without using git.

Support blackened sentinels

Leo's present sentinels contain no space between the opening comment delimiter and the '@' sign that denotes the possible start of a sentinel.  Alas, black inserts a space, thereby destroying Leo's ability to read the external file.

It should be possible to allow exactly one optional space in delimiters just by changing the regex's in fast_at.get_patterns in leoAtFile.py.  This work will be done in a new sentinels branch.

If this work succeeds, it will be possible to blacken any external file using black itself.  Black will know nothing about Leo's sentinels, because they are comments.  If the work fails, then it would be safe only to blacken external files created by @auto, @clean, @nosent and @asis.

Beautify all of Leo's files, in stages

First, I'll disable the new line-breaking code used by beautify-tree.  When all files look good, I'll experiment with breaking lines.  When that works, I'll experiment with joining works. Some of the work can be done in devel.  The new beauty branch will contain more experimental work.

Summary

Leo's black* commands must be removed. They don't work, and can't be made to work.

#1321: Leo's fast-read code should be able to handle blackened sentinels. The sentinels branch will contain this work.

#1322: I'll beautify all of Leo's sources, in stages.  The beauty branch will contain the more experimental parts of this work.

Edward

[Edward K. Ream]

On Tue, Sep 10, 2019 at 2:03 AM Edward K. Ream <edre...@gmail.com> wrote:

> [The black commands] don't work, and can't be made to work reliably...

Heh.  This statement is pretty much totally false.

Both Leo's black and beautifier commands must munge Leo's syntax.  The black commands must "sanitize" Leo's syntax before passing the result to black.  For the beautifier commands, this sanitation is needed only to compare the "before" and "after" ast (parse) trees.

In short, the black commands are coming out of the attic.  I won't blacken Leo's sources, but I will use the black commands as test bed for the revised beautify commands.

Edward

P.S. Testing last night revealed that the beautifier commands presently fail some of the "pet peeves" discussed in pep8.  These must be fixed before I can recommend beautify-tree.

EKR

[Edward K. Ream]

On Tuesday, September 10, 2019 at 8:09:32 AM UTC-5, Edward K. Ream wrote:

> The black commands are coming out of the attic.

Done in recent revs in the beauty branch:

- The black and beauty commands now share a new SyntaxSanitizer class.

As described previously, sanitizing can fail, but it happens only once in Leo's core.  In any case, black can no longer be blamed for any failures.

- The black commands now have better error reporting, similar to the beauty commands.

- Removed some confusing cruft from the BlackCommand cruft.

Summary

Leo's internal black commands are better than ever.

Before improving the beautify/orange commands further, I shall attempt #1321, which would allow Leonistas to run black from the command line on their external files.

Edward

[Edward K. Ream]

On Tuesday, September 10, 2019 at 9:36:39 AM UTC-5, Edward K. Ream wrote:

>> The black commands are coming out of the attic.

> Done in recent revs in the beauty branch.

I forgot to mention that beautify-tree is about 4 times faster than blacken-tree:

black:

scanned 92 nodes, changed 79 nodes, 0 errors in 0.56 sec.

beautify, with orange=False, that is no attempt to split or join lines:

scanned 92 nodes, changed 1 node in 0.14 sec.

I'll attempt to maintain the beautify's speed, but that's not an overriding consideration.

Edward