Open neoscaler opened 3 years ago
Thanks for the request. AFAICT, the reference parser Asciidoctor provides code position information only regarding the line, not the column (or file character) of the currently parsed block. It would be possible to retrieve this information ourselves if the parser worked "gaplessly" (meaning that every source code character would be accessible in the AST), but that doesn't seem to be the case either. Even the line numbers are only available after parsing, and only for the blocks, not for inline elements such as emphasis.
Background: For the mapping of LanguageTool error messages, a full map of source code positions is necessary. LTEX internally converts files to plain text, hands them over to LanguageTool for checking, and obtains a list of spelling errors. This would be possible with Asciidoctor. But to determine which parts of the source code to underline, we have to know which position in the plain text corresponds to which position in the source code.
Mentioning valentjn/vscode-ltex#91 as fixing that would help here as well.
FWIW, it's possible to check arbitrary files as plain text by adding the code language ID such as "asciidoc"
to ltex.enabled
and activating the extension by running LTeX: Activate Extension
. If AsciiDoc is similar to Markdown (which I don't know), we could try to parse it as Markdown to reduce the number of false positives, if that helps.
FWIW, it's possible to check arbitrary files as plain text by adding the code language ID such as
"asciidoc"
toltex.enabled
and activating the extension by runningLTeX: Activate Extension
. If AsciiDoc is similar to Markdown (which I don't know), we could try to parse it as Markdown to reduce the number of false positives, if that helps.
Thanks, this workaround helps, at least for my current work. It checks the files, although we have a lot of false positives in table definitions.
I just want to chime in here with my 2 cents, because I to would love official support for AsciiDoc.
If AsciiDoc is similar to Markdown (which I don't know), we could try to parse it as Markdown to reduce the number of false positives, if that helps.
It is indeed very similar to markdown in it's structure. They mostly differ in details how exactly the format their tags, e.g. a imageblock in AsciiDoc looks like image::some-pic.png[height=300]
. Nothing too out of the ordinary.
In fact I already get great results with manually starting LTeX in AsciiDoc files in VSCode, I just have to disable some rules to get around all the false positives that come from the AsciiDoc tags and blocks.
I hope support for AsciiDoc is possible, it would be a great help!
Is your feature request related to a problem? Please describe. I want to be able to spell check AsciiDoc documents, which are similar to Markdown but with slightly other syntax and more complex features for books.
Describe the solution you'd like Full support for AsciiDoc (language identifier 'asciidoc'). Language specification and information here: https://asciidoc.org/