Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Ascii_tree – A way to create beautiful ASCII trees (github.com/spandanb)
79 points by spanspan on Sept 22, 2019 | hide | past | favorite | 23 comments



I think that with all the unicodes lying around these days we can do a little nicer:

                ┌───┐
          ┌─────┤ 1 ├─────┐
          │     └───┘     │
        ┌─┴─┐           ┌─┴─┐
      ┌─┤ 2 ├─┐       ┌─┤ 3 ├─┐
      │ └───┘ │       │ └───┘ │
    ┌─┴─┐   ┌─┴─┐   ┌─┴─┐   ┌─┴─┐
    │ 4 │   │ 5 │   │ 6 │   │ 7 │
    └───┘   └───┘   └───┘   └───┘
(Better if the presentation doesn't lead beyond the font.)


  I think that I shall never see
  A graph more lovely than a tree.
  A tree whose crucial property
  Is loop-free connectivity.
  A tree that must be sure to span
  So packets can reach every LAN.
  First, the root must be selected.
  By ID, it is elected.
  Least-cost paths from root are traced.
  In the tree, these paths are placed.
  A mesh is made by folks like me,
  Then bridges find a spanning tree.
Radia Perlman, 'Algoryhme' https://web.archive.org/web/20110609192559/http://www.csua.b...

  I hope that we shall one day see
  A graph more lovely than a tree.
  A graph to boost efficiency
  While still configuration-free.
  A network where RBridges can
  Route packets to their target LAN.
  The paths they find, to our elation,
  Are least cost paths to destination!
  With packet hop counts we now see,
  The network need not be loop-free!
  RBridges work transparently,
  Without a common spanning tree.
Radia Perlman in apparent alias as Ray Perlner, 'Algorhyme V2' RFC6325 https://tools.ietf.org/html/rfc6325#section-1.1


This is such a charming poem. I don't like poetry, but there's something special about science poetry.



aaaah the ZX81 semigraphics <3


Ha, didn't expect to see those again. Lovely.


A variation, using stronger lines on the boxes than the lines between them, and curving the corners of the lines:

              ┏━━━┓
        ╭─────┨ 1 ┠─────╮
        │     ┗━━━┛     │
      ┏━┷━┓           ┏━┷━┓
    ╭─┨ 2 ┠─╮       ╭─┨ 3 ┠─╮
    │ ┗━━━┛ │       │ ┗━━━┛ │
  ┏━┷━┓   ┏━┷━┓   ┏━┷━┓   ┏━┷━┓
  ┃ 4 ┃   ┃ 5 ┃   ┃ 6 ┃   ┃ 7 ┃
  ┗━━━┛   ┗━━━┛   ┗━━━┛   ┗━━━┛
Subjectively superior, though the thick lines can be overbearing in some fonts.

Or with doubled lines on boxes:

              ╔═══╗
        ╭─────╢ 1 ╟─────╮
        │     ╚═══╝     │
      ╔═╧═╗           ╔═╧═╗
    ╭─╢ 2 ╟─╮       ╭─╢ 3 ╟─╮
    │ ╚═══╝ │       │ ╚═══╝ │
  ╔═╧═╗   ╔═╧═╗   ╔═╧═╗   ╔═╧═╗
  ║ 4 ║   ║ 5 ║   ║ 6 ║   ║ 7 ║
  ╚═══╝   ╚═══╝   ╚═══╝   ╚═══╝
There are indeed many possibilities!



Ugh, I had forgotten that there are fonts that implement only parts of the box drawing block, absurd though that seems to me—it seems obvious to me that you should implement either all or none of such blocks, and that to do anything else is wrong.


This is very pleasing to me.


Add a pull request? :)


I wish ASCII art would just die. This still looks lousy to me, and now also reminds me that we're trying to draw diagrams by emulating 1980's-era technology. You don't see people still using CGA graphics for clip art.

It was the best we could do, 30 years ago, but today "text" means untrusted Unicode of arbitrary language/script/direction/length, and the number of cases where you can throw it to an output system optimized for displaying "1", "2", "3" is rapidly dwindling.


Honestly, I was hoping for something like the `tree` command. I've implemented that algorithm before, but it was painful and not portable.

These trees are definitely cooler and more complex but maybe fewer use cases. Once you start dealing with more than a few layers, the output is going to line-wrap in a terminal. For larger trees, DOT [1] is probably more suitable.

[1]: https://en.wikipedia.org/wiki/DOT_(graph_description_languag...


DOT is fantastic, and trivial to output, highly recommend it


dot/graphviz is great, but it can take a lot of tweaking and reading to get a good looking graph.


Cool! With some minor alterations you could add support for ditaa output [1]. That would allow you to convert the trees to PNGs.

[1] http://ditaa.sourceforge.net/


The lack of centering is itching my ocd.


Real world or lorem ipsum examples would give a better idea of how beautiful the trees are than just single digits.


Looks like you got your wish


Cool! Maybe a useful feature request: make the output compatible with Markdeep? https://casual-effects.com/markdeep/

I tried Ascii_tree with this online Markdeep demo: https://tomberek.info/markdeep.html and I found that it can work with only minor changes, like using '+' at all the corners and junctions, and wrapping the output in a frame of asterisks '*'.


I have a tool that does a similar thing:

https://github.com/EFanZh/tree-graph-generator

Demo: https://efanzh.org/tree-graph-generator/

But it doesn’t have a good front end yet.


Change requests, options to * make blinking nodes * invert tree

Then we’ll have a Christmas tree generator :)


Beautiful! This will be wonderfully useful for https://algodaily.com




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: