Closed Andrew15-5 closed 7 months ago
Replacing the box(...)
with something reasonable is hard on AST level.
A stopgap is disabling whitespace rules, which are not really usefull for typst documents.
"disabled-checks": [
"WHITESPACE_RULE", // general whitespace rule
"DOPPELTES_LEERZEICHEN", // id for the whitespace rule for the correct language
],
I looked into using the compiled document instead of the Ast to spellcheck and had better results than ast conversion. The problem is running a typst-compiler just for spellcheck or integrating into other compilers (propably LSP).
Hmm, for some reason it doesn't see my disabled checks, but does see changed default language:
local lspconfig = require "lspconfig"
local lspconfigs = require "lspconfig.configs"
lspconfigs.typst_languagetool = {
default_config = {
cmd = { vim.env.HOME .. "/.local/share/cargo/bin/typst-languagetool-lsp" },
filetypes = { "typst" },
root_dir = function()
return vim.fn.getcwd()
end,
},
}
lspconfig.typst_languagetool.setup {
on_attach = on_attach,
capabilities = capabilities,
init_options = {
-- language = "en-US",
disabled_checks = {
"WHITESPACE_RULE",
},
},
}
BTW, can I now remove the LanguageTool Java distribution? Since I no longer have to provide a path to it.
The argument is disabled-checks
with a -
. A warning for unknown fields would help.
The argument is a Vec
, so maybe [
and ]
are required, no clue how lua and serde handle this.
At compile time with maven the classpath for all required java packages is determined and at runtime a JNI JavaVM is started and managed by rust.
Yeah, using -
fixed it:
["disabled-checks"] = {
"WHITESPACE_RULE",
},
Since Rust uses underscore and basically any other language too, maybe you should change it to underscore? Because I see that in VS Code it doesn't matter, and LanguageTool's rules also use underscore. And it would simplify syntax in Lua.
At compile time with maven the classpath for all required java packages is determined and at runtime a JNI JavaVM is started and managed by rust.
I don't understand. Does it find LanguageTool's classes automatically by searching the whole device tree? Where does it get LanguageTool's stuff? I assume not from my custom directory, so I can safely remove it, for both compilation and runtime.
Theres is a warning for unknown options and I changed the names to snake_case
.
At build time the command mvn dependency:build-classpath
is run and the result is embedded in the executable.
The command resolves dependencies, downloads the packages and prints the saved location.
For me all the jar files are under C:/users/anton/.m2/repository/...
and no local jar files are required.
Theres is a warning for unknown options and I changed the names to
snake_case
.
Thanks!
At build time the command
mvn dependency:build-classpath
is run and the result is embedded in the executable. The command resolves dependencies, downloads the packages and prints the saved location.
Oh, ok then. So there is a LanguageTool library in Maven? I thought it's only available as a distribution. So it now has a full JVM inside Rust binary? That is so cool! So you don't even depend on local Java version, right? Which means not only it doesn't require LanguageTool distribution, it also doesn't require Java! And yet the binary is only 2.24 MiB, this is very impressive.
The JNI requires an installed java runtime. The Rust code loads a dynamic library for the java runtime.
Mmm, I see. Thanks for the explanation.
https://dev.languagetool.org/java-api.html Languagetool is available as a normal maven package to use.
Spellchecking is now after the document compilation, so this should not happen anymore. If the issue still exits, please reopen the issue.
A small cut-out from a template:
There are 3 key whitespaces that causing this. By far the most annoying part is that the error is expanded to many lines even though it should be a one-line "mistake". But since
#box()
is just a wrapper for text (repeated string) the error is false.