Sysmagine
Add AsciiDoc support
I am pretty frustrated with standard document workflows involving PDF and MS Word.
It would be beyond amazing to be able to work in a documents-as-code fashion using AsciiDoc + SemanticDiff + MergeBoard, especially now that AsciiDoc is being standardised under the Eclipse Foundation.
This use case has a potential market that goes beyond coding and programmers, but any organisation or individual working with documents.
I hope it is feasible and not too difficult to implement; there are already parsers that produce the AST of an AsciiDoc file.
An AST is technically not sufficient for adding support for a new language / file format in SemanticDiff. ASTs often store information in an abstract format (e.g. a boolean to indicate whether a function is async) and don't expose which token in the text leads to this interpretation. We therefore work with Concrete Syntax Trees (CST), which have a 1:1 mapping for each input token to a corresponding node in the tree.
I glanced over the linked parser and it seems that it uses an AST and stores the location information only on a line-number granularity. This would not be sufficient for SemanticDiff. We would probably need a different parser to add support.
This use case has a potential market that goes beyond coding and programmers, but any organisation or individual working with documents.
They probably won't use VS Code or a GitHub App and we would need to provide a completely different frontend for such an audience 😉️.
Just out of curiosity, what is your use case for AsciiDoc?
FWIW, if you can convince document authors to follow something like https://asciidoctor.org/docs/asciidoc-recommended-practices/#one-sentence-per-line then a raw (or --word-diff) diff should be good enough. But if authors set their text editors to wrap text to some margin without regard to meaning, then a plain diff is junk.
We are currently extending the SemanticDiff GitHub App with additional diff modes. This includes a word diff and should make it easier to review text even if the format is not yet supported by SemanticDiff. For the word diff, it shouldn't matter if the text is manually wrapped, since line breaks are ignored in this mode.