

Show HN: Indented outline to graphviz - chestervonwinch
https://github.com/notmatthancock/outline_to_graphviz

======
veli_joza
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.

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

~~~
qznc
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".

------
pvaldes
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"

~~~
chestervonwinch
> 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.

~~~
pvaldes
> 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...]

~~~
chestervonwinch
I think the counter is great idea. Thanks.

------
chestervonwinch
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.

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

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

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

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

------
melling
How about processing simple Markdown?

# main

## topic one

### subtopic one

## topic two

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

~~~
melling
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.

~~~
jerf
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.

