Add support for graphviz
Hey @AndrewRadev
I really enjoy your plugin and the way you really quickly include new feature requests. Thus, in any circumstance I would want to split anything, I am thinking to request it here. Now I will do so for graphviz's dot language for graph specification. The syntax of edges is rather simple:
A -> B, C
creates two edges from the node A to both the node B and C. Now, at some point you want to add a label to one specific edge. They have to be splitted.
A -> B;
A -> C [label="edgy"];
The other way round:
A -> B;
A -> C;
could be joined into A -> B,C.
Please note that multiple elements on the left-hand side are also allowed. This could make splitting things more difficult, but also simplify joining. Thus the following two variants are also equivalent.
A, B -> C, D
A -> C;
A -> D;
B -> C;
B -> D;
I propose to not split or join anything with a square bracket inside, since you can make no assumptions to which edge the attributes belong.
It is not very urgent, but just another nice use-case for your plug-in. I could also try to work on it in the beginning of april by myself.
I'll see what I can do about it. It shouldn't be particularly hard to pull off. I'd definitely appreciate a PR, if you can spare the time to try it out, even if it's incomplete.
For now, one thing I'm wondering is what the format of the node names can be. Is it allowed to have something like "foo bar" -> "baz", or is it just word characters?
Yes something like "this is a label" is also allowed, but as far as I know, those two options are the only ones. \i\+ or "[^"]\+". I will create a PR with my initial attempts during the next week.
Hey @AndrewRadev, Just to let you know, I am making some progress: split is already working (but not robust yet). For the joining, I encountered a little algorithmic problem: In the end: we need an edge between all source nodes and all destination nodes in order to join. But when do we stop? Heuristically, on a blank line? Just consider the example from above:
A -> C;
A -> D;
B -> C;
B -> D;
while having the question in mind: How to decide whether to take the next line into account? Of course they can also be shuffled around. Do you have an idea?
I actually wouldn't try to be too clever about this. The way I imagine this particular example to work is in these phases:
A -> C;
A -> D;
... goes to ...
A -> C, D;
B -> C;
B -> D;
... goes to ...
B -> C, D;
A -> C, D;
B -> C, D;
... goes to ...
A, B -> C, D
So, if you have the exact same text on the left, or on the right, you can join the other sides, otherwise just don't do anything. If they're reordered, the user can easily order them correctly with a couple of dds and pastes.
#109