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.
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
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.
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.
17 comments
[ 2.7 ms ] story [ 46.4 ms ] thread# main
## topic one
### subtopic one
## topic two
I also have md on Github that I might want to use.
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.
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.
OK, there is "A -> B; A -> C" vs "A: B C".
However, also "A -> B -> C" vs "A: B\nB: C".
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.
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"
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.
Something like this should be enough
Or alternatively you can use a counter. If you avoid spaces you can also forget the quotes (but quotes are safer) But avoid to name nodes with '_' and '.'