New odt output format: dtsc

[lucasvr]

The new format generates a dts-like output, but comments from the input
files are spliced back into the merged tree before pretty-printing.

Builds on top of PR #14

[a6f]

I think this might be done more cleanly with a new implementation of merge(). Manually tracking source positions and reconstituting spans is definitely going around the parser instead of using it to give structure to the input.

Much of the difficulty here is with how pest handles trivia. A model which attaches it to an adjacent non-trivial node could help here, and would also help with some difficult cases in the pretty-printer.

What application do you have in mind for this?

[lucasvr]

I think this might be done more cleanly with a new implementation of merge(). Manually tracking source positions and reconstituting spans is definitely going around the parser instead of using it to give structure to the input.

Much of the difficulty here is with how pest handles trivia. A model which attaches it to an adjacent non-trivial node could help here, and would also help with some difficult cases in the pretty-printer.

What application do you have in mind for this?

I'm mostly looking for an API that works like odt -I dts -O dtv while merging + preserving comments. The UI of the clocktree editor appends a new / { } block each time the user wants to save changes made to the graph, but the series of appends doesn't generate a pretty-looking file.

[a6f]

I'm mostly looking for an API that works like odt -I dts -O dtv while merging + preserving comments. The UI of the clocktree editor appends a new / { } block each time the user wants to save changes made to the graph, but the series of appends doesn't generate a pretty-looking file.

Maybe we could implement something more restricted which can handle that. Does the editor emit comments or deletions? If all it does is set properties, maybe we could inject those directly at the site of the definitions they replace. Or we could only merge a comment-free pair of blocks at the bottom of the file, instead of having to come up with semantics for merging comments.

[a6f]

Hmm. Consider:

// comment 1
/ {
    // comment 2
    soc {
        // comment 3

        // comment 4
        /delete-node/ dev@0;
    };
};

Arguably we should discard all of these comments, since the whole block is likely redundant after merging. Comments 1-3 might have something interesting to say, but it's unclear where to place them that won't be confusing. You almost want to ask an LLM if moving them has preserved their meaning or not....