That's an interesting idea, and an unexplored design space. Graphviz's dot has rank and head/tail ports, and Plantuml's class diagram has some support for relative position, but both are more hints for the layout engine, not deterministic declarations. If I had a nickel for every hour I spent fiddling with a Plantuml diagram to get the relation directions to force the layout into at least an approximation of what I wanted, I'll be a lot closer to retirement.
I like that you're going for one generic syntax instead of many specific ones, like mermaid and Plantuml, but it's as much as a pro as it is a con, it's one reason why these languages evolved in the first place, instead of everyone just using DOT. One possible mitigation would be some sort of reuse mechanism? Some way that generic nodes could be defined once and instantiated many times, so if I wanted to draw something like a sequence diagram, I could define/change my participant lanes just once.
Another issue the "No multi-line statements, no line continuations, no blocks." philosophy. I get *why* you chose it, and has its advantages, but it's a pretty annoying constraint, specially if one wants to have longer node names, or have more detailed description of the node in its label, like listing the responsibilities of a class, for instance. "No blocks" is something that can probably won't make much difference, but line continuations (i.e., some distinction between physical and logical lines) can make or break the user experience, IMHO
The syntax for line breaks is another thing I urge you to reconsider, '/' is waaay to common of a character, and being forced to write long strings in a single line can get *really* annoying. Some sort of multiline string support would really make your existing syntax shine.
The last two suggestions/complaints would complicate your parser a lot, specially since you're writing it manually, so, they are trade offs, but as a user who'd love to have something like this on my toolbelt, not having these features would make me hesitate a lot on investing time in this tool.
That said, it's a nice idea, I'll keep an eye on it =)
Thanks! Some serious food for thought. Next up, I'm planning on custom attributes, functions, etc. that a user doesn't have to use, but a more programmer-oriented user would probably enjoy having access to. But, I think I see what you're saying about a sequence diagram and that would only be a partial answer. I'll have to give that more thought!
And, I'm not wedded to the "no multi-line statements". That's more a philosophy of the super early versions of keeping it simple. I noticed some of the playground examples could already benefit from even simple line continuation. The philosophy there would be, if people don't like line continuation, they don't have to use it, but for those who want it, give them a convenient way to do it. Good point about the forward slash char... so much food for thought. Really appreciate the thoughtful comment.
Frankly for all it's issues, plantUML has been the most customizable and flexible for me. Mermaid is fine for diagrams where you don't need to customize the look and feel much; it starts to become a pain once you need to. I just wish Obsidian had as a good a support for plantUML as it does for Mermaid.
I kinda agree, and I mostly switched to mermaid because of availability. Plantuml is much more annoying to setup, and doesn't render natively on GitHub (last I checked, anyway), so if I writing anything more collaborative, mermaid requires a lot less explanation or help with setup.
And for me, one mediocre tool that works everywhere for everything beats a better tool that requires me to context switch too often, so I mostly retired Plantuml. Not happy about, but alas.