Closed DanielSWolf closed 2 years ago
+1
Thanks for filing this issue @DanielSWolf
It's correct that this doesn't work. But I'm not sure to what extent we should aim for feature parity between different processors and runtimes in this extension.
There are many different command line options for this extension:
In future I expect these options to expand further (GraalVM for example).
What is the reason you use a different runtime -- is it because you are using extensions?
I think it is outside of the scope (and would be a significant amount of work) to support all the different runtimes. We use extensions to generate some of the information that the extension processes and we also directly use the Asciidoctor.js API. We don't have (easy) access to the API of other runtimes.
There has been some upstream discussion about making the Asciidoctor (and Antora) ecosystem support the idea of exporting a "manifest" which could contain information to aid processing. This would allow the extension to use any runtime (I've filed upstream https://github.com/asciidoctor/asciidoctor/issues/3588).
I'm interested in the thoughts of others (any ideas @joaompinto?).
@danyill I agree with your oppinion, what I have been considering for some time was to actually remove the "use_asciidoctor_js" option and enforce AsciidoctorJS which is already a bundled dependency.
Are there any cases (in the specific context of the vscode extension) where using the Ruby version would bring notable benefits over AsciidoctorJS ?
One case I have is that I use plantUML diagrams in my documents.
I don't have access to Kroki and can't send the diagrams out on the internet. So I add the "-r asciidoctor-diagram" to the command for the Ruby version to get it rendered.
Syntax highlighting is also not rendered properly in the preview when using use_asciidoctor_js: true
, making the preview not resemble the actual pdf output. The Ruby version works just fine.
@SjoerdV could you please open a new issue with a reproduction case or a bit more context/information to reproduce this issue?
@Mogztter, it's actually not a new issue since it is caused by lack of support for the additional source highlighters like rouge and pygments in the preview when using the JS version. See: #315
I was answering the question by @joaompinto
Are there any cases (in the specific context of the vscode extension) where using the Ruby version would bring notable benefits over AsciidoctorJS ?
And please do not 'remove the "use_asciidoctor_js" option'
OK, understood, I was a bit confused by your initial comment.
Syntax highlighting does work in Asciidoctor.js (with Highlight.js) but Rouge (Ruby library) and Pygment (Python library with a Ruby binding) syntax highlighters are indeed not available in a JavaScript environment.
So that's one benefit of using asciidoctor
command line over Asciidoctor.js.
Scroll sync can't work with asciidoctor
(binary) since source map is not exported from the command line.
In addition, Asciidoctor CLI support has been removed.
Description
If the option
Use_asciidoctor_js
is active, the scroll positions of editor and preview are synchronized as expected. However, ifUse_asciidoctor_js
is not active, scrolling one won't scroll the other.System Information