Label quoting remains in the parsed results #7

eras commented 2025年06月15日 17:25:16 +02:00

When running cargo run --examples extract_labels (after slightly fixing it to allow it to compile, by using format string {:?} where required), I see the following in its output:

C -- AList { elems: ["\"label node C\""] }

I would expect the quoting to be removed from the label, even though GraphViz allows both quoted and unquoted strings. (This is what the less maintained https://github.com/saresend/dotfile-parser/ did.)

Alternatively there should be a function for unquoting the string, though I would consider this a worse alternative.

When running `cargo run --examples extract_labels` (after slightly fixing it to allow it to compile, by using format string `{:?}` where required), I see the following in its output: ``` C -- AList { elems: ["\"label node C\""] } ``` I would expect the quoting to be removed from the label, even though GraphViz allows both quoted and unquoted strings. (This is what the less maintained https://github.com/saresend/dotfile-parser/ did.) Alternatively there should be a function for unquoting the string, though I would consider this a worse alternative.

eras commented 2025年06月15日 18:18:34 +02:00

..and the example can also be run directly with cargo run -F display --examples extract_labels, which which case the output is

C -- "label node C"; 

i.e. the quotation is still present, as the printing code doesn't add it.

..and the example can also be run directly with `cargo run -F display --examples extract_labels`, which which case the output is ``` C -- "label node C"; ``` i.e. the quotation is still present, as the printing code doesn't add it.

bromind commented 2025年06月15日 19:16:02 +02:00

Correct, I'll fix that on Tuesday.

(Note to myself: this can easily be solved with silent rule in the pest file).

Correct, I'll fix that on Tuesday. (Note to myself: this can easily be solved with silent rule in the pest file).

bromind commented 2025年06月17日 21:30:18 +02:00

#e5a49a6ca2 should address this issue. It turned out to be slightly more complex than I expected to do that in a clean way. In particular, it changes slightly the interface. Now, instead of parsing a Graph<(&str, &str)>, we parse a Graph<(ID<'_>, ID<'_>), where ID<'a> is a thin wrapper over &'a str, required to implement the parsing interface.

It might change a bit in the future. In particular, I'm not really happy by the way that ID in Graphviz grammar do not explicitly appear in the struct. Sometimes they are String, sometimes they are something else.

Btw, @eras, I've checked your graphpipe project on github. I've seen that your parse_graphviz function converts a graphviz description into petgraph. In case you haven't see the latest petgraph update, it is now interfaced with dot-parser, thus you can directly read petgraphs from graphviz (https://github.com/petgraph/petgraph/releases/tag/petgraph%40v0.8.2). I don't know if it work in your case, as you also build id_maps, and I didn't spend a lot of time understanding why you do that; but if you don't really need those maps, it might significantly ease your parse_graphviz function.

#e5a49a6ca230db8e0611333cc50585956872d142 should address this issue. It turned out to be slightly more complex than I expected to do that in a clean way. In particular, it changes slightly the interface. Now, instead of parsing a `Graph<(&str, &str)>`, we parse a `Graph<(ID<'_>, ID<'_>)`, where `ID<'a>` is a thin wrapper over `&'a str`, required to implement the parsing interface. It might change a bit in the future. In particular, I'm not really happy by the way that `ID` in Graphviz grammar do not explicitly appear in the struct. Sometimes they are String, sometimes they are something else. Btw, @eras, I've checked your graphpipe project on github. I've seen that your `parse_graphviz` function converts a graphviz description into petgraph. In case you haven't see the latest petgraph update, it is now interfaced with dot-parser, thus you can directly read petgraphs from graphviz (https://github.com/petgraph/petgraph/releases/tag/petgraph%40v0.8.2). I don't know if it work in your case, as you also build id_maps, and I didn't spend a lot of time understanding why you do that; but if you don't really need those maps, it might significantly ease your `parse_graphviz` function.