Show HN: Indented outline to graphviz | Hacker News Reader

Show HN: Indented outline to graphviz

github.com

There's a quite obvious need for a more elegant graph description syntax than DOT language. Preferably something simpler and easily remembered. I think this script is a step in the right direction, but obviously it only scratches the surface of what graphviz can do.

The nice approach would be to take cue from HTML and separate content from presentation. As for syntax, something lightweight with as little braces/operators/interpunction as possible.

I agree, dot is a horrible language. I say that as someone who uses it every day. One of my earlier python experiments was to build a tool to take csv's and covert them to dot language. I started building a web interface around it as well, but left it on the shelf shortly after. https://github.com/gardenmwm/pydepgrapher

Don't makefiles essentially encode a direct acyclical graph of dependencies? They've got quite simple syntax.

The difference is "A -> B" vs "A: B".

OK, there is "A -> B; A -> C" vs "A: B C".

However, also "A -> B -> C" vs "A: B\nB: C".

Interesting but also prone to errors. Subtopic one (in topic one) will be different as Subtopic one (in topic two) in most real cases, probably. A clear example is scientific literature where each chapter could have a 'results' section, maybe with different subsection names.

The reverse situation can be also a problem. 'Subtopic one', 'subtopic one' and 'subtopic One' for example, are taken as three different nodes. This can either be good or bad.

Other problem is that your code generates a bad graph when you have a " in the infile. Try it with: Topic "Two"

> Subtopic one (in topic one) will be different as Subtopic one (in topic two) in most real cases, probably. A clear example is scientific literature where each chapter could have a 'results' section, maybe with different subsection names.

I agree. In fact, I set out to make it this way initially. It's either more difficult to implement this, or I don't know the dot language well enough - probably the latter.

I did a dirty hack to do exactly what you're saying for a scientific paper. I modified the code to check if the current line/topic/node was already mentioned in the output string. If so, I tacked on a random number to the node name. Yuck.

Ideally, there would be option to preserve a strict tree-like architecture in better way.

> It's either more difficult to implement this

Something like this should be enough

    "topiconesubtopictwo" [label = "subtopic two"];
    "topictwosubtopictwo" [label = "subtopic two"];

Or alternatively you can use a counter.

    12 [label = 'subtopic two'];
    22 [label = 'subtopic two'];

If you avoid spaces you can also forget the quotes (but quotes are safer)

     topiconesubtopictwo [label = "subtopic two"];

But avoid to name nodes with '_' and '.'

     topic_one_subtopic_two [label, etc...]
     topic.one.subtopic.two [label, etc...]

I think the counter is great idea. Thanks.

Perhaps I should share my reason for creating this:

I was reading (long) literature review and wanted to create a condensed outline of the topics while preserving the hierarchies. An indented list of keywords was a natural way to do this while reading. Afterwards, I was interested in visualizing the result.

Can you share a pic of the output, for lazy people like me?

Sure. Updated readme contains commands to generate the associated image using dot.

Thanks for the update - it does what I thought it would.

It's pretty close to YAML; so you might as well use that.

How about processing simple Markdown?

# main

## topic one

### subtopic one

## topic two

What's the advantage of that? (It's not like you're going to get to use hardly anything else from Markdown.)

I was thinking of the Use Case where you take some existing Markdown. Apple is going to use it in their Notes app, for example, so it might become even more popular.

I also have md on Github that I might want to use.

Oh, I wouldn't Markdown that represents real documents to produce anything useful, so I just automatically skipped that possibility.

If you've got a real document that produces a non-trivial graph when you render its headers this way, you've probably got yourself a really, really poorly written document. Written text needs to have been serialized somehow, and as a side effect, you'll make the graphviz view of the document pathologically uninteresting. Conventional outline views are much better suited for written text.

Reply on news.ycombinator.com