This grammar is 3 years old, there's a better grammar out there!

[NormanDunbar]

I see nothing has happened here for 3 years, I'm not complaining by the way, but I'm wondering if you have seen this grammar, which appears to be a lot more complete?

https://github.com/venkatperi/asciidoc-antlr

I've downloaded it and compiled it (without gradle etc) and it manages to parse a few of my test files. It doesn't cope with its own 1.adoc and 2.adoc which may be deliberately set up with errors, I'm not sure. It does parse its own sample.adoc though.

Compiling (on Linux) with ANTLR 4.7.1:

Once only, create an out of source build directory:

cd asciidoc-antlr
mkdir normsBuild

Once per session, set up the environment:

cd asciidoc-antlr/normsBuild

# Assumes grammars etc are in the asciidoc-antlr directory above the current one.
#
export SRC=../asciidoc-antlr/src/main/antlr
export SRCJ=../asciidoc-antlr/src/main/java/AbstractAsciidocLexer.java
export CLASS=$SRCJ/AbstractAsciidocLexer.class

# Assumes ANTLR4 jar file is in the ANTLR4 directory above the current one.
#
export CLASSPATH=".:../ANTLR4/antlr-4.7.1-complete.jar:$CLASSPATH"

# Where is your Java Home?
#
export JAVA_HOME=whatever
export PATH=$JAVA_HOME/bin:$PATH

# A couple of useful alias names
#
alias antlr4="java org.antlr.v4.Tool"
alias grun="java org.antlr.v4.gui.TestRig"

Once per build, compile the grammar:

antlr4 $SRC/AsciidocLexer.g4
antlr4 $SRC/AsciidocParser.g4

# Not strictly necessary every time, but ...
#
javac -cp $CLASSPATH *.java $SRCJ
cp $CLASS ./

And, finally, testing a build:

grun Asciidoc asciidoc -tree yourfile.adoc

Replace -tree with the appropriate grun option. (Run grun with no parameters for details.)

HTH

Cheers, Norm.

PS. I've forked this to https://github.com/NormanDunbar/asciidoc-antlr in case the original ever goes away! Plus, I might, eventually, get some time to look into it.

[tobiashochguertel]

@NormanDunbar Thanks!

[mojavelinux]

I think it's time to sunset this project. We're going to instead work on a treetop-based grammar, first by focusing on the inline parsing. You can find that prototype here: https://github.com/Mogztter/asciidoctor-inline-parser

I'm still unsure whether the whole documentation should / can be represented by a single grammar because the AsciiDoc language is contextual. What gets parsed is sometimes affected by the content. Therefore, I think a better strategy is to use parser grammars as a tool to help with the parsing, but ultimately the parser will be a hybrid. (But I could end up being wrong).

The referenced project is certainly helpful in moving the conversation forward.