Status of various beautification issues

29 views
Skip to first unread message

Edward K. Ream

unread,
Sep 13, 2019, 9:30:40 AM9/13/19
to leo-editor
This page lists all issues labelled "Beautify".  I have spent several hours bringing them up to date.

Highlights of recent work

1. In an earlier post I said, "Shall not beautify Leo's sources.  Not now.  Not ever".

Hehe, that statement has been relegated to the dust bin of history :-)  See #1272 and  #1325.

The SyntaxSanitizer class prevents black from doing bad things to comments. By default Leo's blacken and beautify commands preserve leading indentation in stand-alone comments.  The SyntaxSanitizer class allows the beautify commands to verify that they don't change the meaning (parse trees) of the code.

Nevertheless, #1322 (beautify/blacken Leo's sources) is a low priority project.

2. Orange is a now only a project name.  See #1266: Orange is the new black.

All black-related settings start with "black-".  All orange-related settings start with "beautify-".

Summary

The Beautify label allows us all to see all the related issues.

It is now safe to blacken (or beautify) Leo's own sources.  Nevertheless, #1322 is a low priority project.

"Orange" is now only a project name.  All beautifier settings start with "black-" or "beautify-"

The black and beautify commands aren't really worth any amount of work, but finishing them is :-) Maybe a few more days...

All questions and comments welcome.

Edward

Edward K. Ream

unread,
Sep 13, 2019, 11:22:52 AM9/13/19
to leo-editor
On Friday, September 13, 2019 at 8:30:40 AM UTC-5, Edward K. Ream wrote:

At present the split/join logic in the beautify-tree command is causing errors. I'll get to them soon.

Nevertheless, the beautify-tree command is usable. For now, use the beauty branch.  Errors in a particular node are reported succinctly. Errors never corrupt the file, because p.b is not updated in those cases.

Some statistics:

beautify-tree (Core classes) **without** split/join logic:
scanned
3303 nodes, changed 393 nodes, 0 errors in 4.89 sec.

beautify
-tree (Core classes) **with** split/join logic:
scanned
3303 nodes, changed 377 nodes, 72 errors in 6.39 sec.

All unit tests pass either way.

As you can see, the split join logic increases running time, but not by a lot. The beautify-tree remains significantly faster than blacken-tree.

Edward

Edward K. Ream

unread,
Sep 13, 2019, 12:51:13 PM9/13/19
to leo-editor
On Fri, Sep 13, 2019 at 10:22 AM Edward K. Ream <edre...@gmail.com> wrote:

As you can see, the split join logic increases running time, but not by a lot. The beautify-tree remains significantly faster than blacken-tree.

I'm not completely sure of this last statement.  Anyway, the speed of all these commands makes no difference.

Crucially, both Leo's blacken and beautify commands ensure that the meaning of a program remains unchanged, by comparing the "before" and "after" parse trees after calling black.format_str.

Black itself makes no such guarantee. Apparently, black.format_str simply returns an unchecked result!

Edward

Edward K. Ream

unread,
Sep 13, 2019, 6:22:54 PM9/13/19
to leo-editor
On Friday, September 13, 2019 at 11:51:13 AM UTC-5, Edward K. Ream wrote:

Crucially, both Leo's blacken and beautify commands ensure that the meaning of a program remains unchanged, by comparing the "before" and "after" parse trees after calling black.format_str.

Black itself makes no such guarantee.

Yes it does, provided the fast option is off.

Edward
Reply all
Reply to author
Forward
0 new messages