You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is capable of using as much space as possible - child branches can overflow under sibling parent branches, which makes the tree look a lot more compact. Something like that would be nice to have
Another nice feature would be to compress row spacing to compress rows:
ALSO when I pulled and debugged your lib, I saw there are a lot of writes and changes to the LineBuffer, as well as methods that return encoded values (like array of 2 elements encoding properties like position and width — maybe use records or classes with meaningful fields for them?). Maybe it would be possible to avoid changes like that if you had a dynamic list elements per row (like pad, branch, node, branch, pad) which is rewritten in some kind of two-pass bottom-up + top-down fashion?
The text was updated successfully, but these errors were encountered:
Thank you for your request. I once planned to implement a compact binary tree printer and some compactness options for TraditionalTreePrinter.
It's a serious difficulty that each node's content can have different heights and insets (multiline nodes are first-class citizens). I wouldn't be surprised if this is a computationally hard problem (in any case, a weighted MAX-SAT solver could still help).
I'll think about it some more, so I will leave this open for now.
Take a look at https://github.com/billvanyo/tree_printer.
It is capable of using as much space as possible - child branches can overflow under sibling parent branches, which makes the tree look a lot more compact. Something like that would be nice to have
Another nice feature would be to compress row spacing to compress rows:
ALSO when I pulled and debugged your lib, I saw there are a lot of writes and changes to the
LineBuffer
, as well as methods that return encoded values (like array of 2 elements encoding properties like position and width — maybe use records or classes with meaningful fields for them?). Maybe it would be possible to avoid changes like that if you had a dynamic list elements per row (likepad, branch, node, branch, pad
) which is rewritten in some kind of two-pass bottom-up + top-down fashion?The text was updated successfully, but these errors were encountered: