asciidoctor / asciidoctor-vscode

AsciiDoc support for Visual Studio Code using Asciidoctor
Other
326 stars 98 forks source link

Scroll sync not working with Ruby asciidoctor #210

Closed DanielSWolf closed 2 years ago

DanielSWolf commented 5 years ago

Description

If the option Use_asciidoctor_js is active, the scroll positions of editor and preview are synchronized as expected. However, if Use_asciidoctor_js is not active, scrolling one won't scroll the other.

System Information

cscalfani commented 4 years ago

+1

danyill commented 4 years ago

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?).

joaompinto commented 4 years ago

@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 ?

DaLynxx commented 3 years ago

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.

SjoerdV commented 3 years ago

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.

ggrossetie commented 3 years ago

@SjoerdV could you please open a new issue with a reproduction case or a bit more context/information to reproduce this issue?

SjoerdV commented 3 years ago

@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'

ggrossetie commented 3 years ago

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.

ggrossetie commented 2 years ago

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.