Why would someone choose this over DOT?
DOT seems like a really robust, expressive language. Maybe at some point I'll to write something that transforms from this syntax to DOT.
The result is that it’s very challenging to type syntactically correct dot at “line-speed”, e.g., if one is taking notes.
(This is one of several reasons that I think there is definitely still room for improvement in notation for graph-drawing, as I have begun exploring in my own work.)
It's a disappointment or even failure of our current language scanning and parsing tools or, really, the way we used them, that this is not an easy exercise.
This way, simple lists can be specified via juxtaposition:
a b c
And then more complex lists
thing 1, thing 2, thing 3
and still more complex lists like
A complex thing; with data, and more data
can be specified in a way that is potentially still human-legible and easily editable.
Combined with ~instant feedback while typing and, ideally, a “brushing” system to allow selection of parts of the textual model via the linked drawing, I am hopeful that this can be solved resiliently, at least for the most common use cases.
(Part of why I am excited about OP’s work here though is that while I have done a fair bit in my own project on drawing a related kind of diagrams, I have myself only begun thinking about how to make the resulting drawings nicely stylable/themeable.)
[1] https://mstone.info/depict/ -> https://github.com/mstone/depict
It leaves me wondering: if somebody carefully looked at all the languages and all the use cases, is it possible to build a single language that does it all while still being easy for smaller charts? Or are the goals of easy and complete in too much tension, such that we're better off with a bunch of languages, each one tuned for making things easy in a particular zone of the problem space?
What I think may emerge though is a better shared understanding of “what’s needed” as well as a great (ideally libre) library for implementing those ingredients consistently and interoperably — e.g., a DOM/CSSOM for these graphs as well as maybe an adaptagrams- or cairo-like library for the common layout and drawing capabilities.
(For example, have you noticed how many general-purpose drawing tools now have “align and distribute” capabilities that all work similarly? AIUI, many of those tools are either directly using or are inspired by Kim Marriot, PJ Stuckey, Tim Dwyer, & colleagues’ work in this area?)
---
#token Some Node That is Referenced Often
other node A
(#token)
(#token)
other node D
(#token)So if your markup was:
```
#parentA Start 'Welcome Node'
#childA /1 "this node has a
```
That could be "tokened" as
[
{
tokenType: "ID"
value: "parentA"
decorators: [{ "character": "#", indexes: [0]}]
},
{
tokenType: "CONTENT"
value: "Start"
decorators: null
},
{
tokenType: "TITLE"
value: "Welcome Node"
decorators: [{character: "'", indexes: [0, 13]}]
},
...
]
So it could be that you can read multiple different syntaxes into the same tokenizations.
Like
```
#parentKey parent
#childKey child
#childKey -> #parentKey /north
```
could be equivalent to
```
#parentKey parent
#childKey child /north