We use AsciidoctorJ. Spring is written in Java, so we prefer other things that are written in Java. Part of the team's excitement about the Working Group is that there will be a Java implementation.
That shouldn't matter, though. IMO, the Asciidoc specification should provide extension mechanisms regardless of the language that implements the specification. In other words, I would like the specification to call out extension mechanisms. The XSLT specification
does so, for example:
https://www.w3.org/TR/xslt-30/#extension (and did so in its previous versions, though each one did it differently).
Hi Jay,
Looking at the repo, it appears to be a mix of ruby and java code. Which “dialect(s)” of Asciidoctor are you (Spring) using, called how?
I’m much more familiar with the _javascript_ and ruby dialects than java. It looks like it is considerably more awkward to implement processor extensions in java than other languages.
I think it’s possible that there are existing more efficient ways to implement some extensions in current Asciidoctor, such as using the template converter system for your converter extension.
Other than the possible difficulty of implementing string manipulation in java, and relating java extensions to a ruby backend, I’m curious what specifically you would like to be easier.
I always like looking at what people do to extend Asciidoctor :-)
Thanks
David Jencks
Hi, all,
First, some background (I must tell you this bit so the rest might make sense): The Spring Framework is really more than 50 different projects. Almost all of those projects use Asciidoc (and Asciidoctor). We have gotten into the all-too-common state of different
projects doing very similar things in different (or even the same but copied) way.s To that end, we have started a project to provide one source for the features we want (code folding, tabbed content, copy-to-clipboard, dark mode, and others). Here's that
project:
https://github.com/spring-io/spring-asciidoctor-backends/
I mention it here to point out the kinds of things that people try to do. I do not expect the Asciidoc WG or any implementation to do these things for us. However, I would like us to think about any "hooks" we can put in the spec and the resulting implementations
to make implementing these kinds of features easier.
Thanks.
J
_______________________________________________
asciidoc-lang-dev
mailing list
asciidoc-lang-dev@xxxxxxxxxxx
To
change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/asciidoc-lang-dev
