4 ms·

In my experience, typing dot requires a lot of quoting and brace-matching, often in editors without the best affordances for those operations, with so-so error

In my experience, typing dot requires a lot of quoting and brace-matching, often in editors without the best affordances for those operations, with so-so error reporting. 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.)

graphviz 4y ago
That's interesting. It's not hard to see the problem. HTML labels don't help, either. How do other languages solve this? Like, a shell HERE document that has one fixed string as a terminator? The graphviz lexer https://gitlab.com/graphviz/graphviz/-/blob/main/lib/cgraph/scan.l https://gitlab.com/graphviz/graphviz/-/blob/main/lib/cgraph/... seems hackable but disabling downstream processing of escapes elsewhere would be necessary too. Possibly this would mean bypassing some of the processing in the function make_label in https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/labels.c#L113 https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/... 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.
- anoncept 4y ago
  One potential solution direction, which you can try out via my own incomplete drawing toy [1] is to treat punctuation characters like SP (“ “), COMMA (“,”), and SEMICOLON (“;”) as markers for the product operations of a family of monoids that allow you to specify more and more complicated sequences without requiring the typist to “move the cursor left” to add a matching character. 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://mstone.info/depict/ -> https://github.com/mstone/depict https://github.com/mstone/depict

graphviz 4y ago

That's interesting. It's not hard to see the problem. HTML labels don't help, either. How do other languages solve this? Like, a shell HERE document that has one fixed string as a terminator? The graphviz lexer https://gitlab.com/graphviz/graphviz/-/blob/main/lib/cgraph/scan.l https://gitlab.com/graphviz/graphviz/-/blob/main/lib/cgraph/... seems hackable but disabling downstream processing of escapes elsewhere would be necessary too. Possibly this would mean bypassing some of the processing in the function make_label in https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/labels.c#L113 https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/... 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.

anoncept 4y ago
One potential solution direction, which you can try out via my own incomplete drawing toy [1] is to treat punctuation characters like SP (“ “), COMMA (“,”), and SEMICOLON (“;”) as markers for the product operations of a family of monoids that allow you to specify more and more complicated sequences without requiring the typist to “move the cursor left” to add a matching character. 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://mstone.info/depict/ -> https://github.com/mstone/depict https://github.com/mstone/depict