Support class and style files

[LDAP]

Is your feature request related to a problem? Please describe.
LTEX-LS reports a lot of false positives in cls and sty files.

Describe the solution you'd like
Support cls and sty files.

Related question
Does LTEX-LS distinguish filetypes over languageId or by file extension? Is LaTex filtering of commands disabled if the languageId (or extension) does not match?

[LDAP]

If I interpret these lines correctly:

ltex-ls/ltexls-core/src/main/java/org/bsplines/ltexls/server/LtexWorkspaceService.java

Lines 76 to 77 in 403f315

	@Nullable String codeLanguageId = (arguments.has("codeLanguageId")
	? arguments.get("codeLanguageId").getAsString() : null);

ltex-ls/ltexls-core/src/main/java/org/bsplines/ltexls/server/LtexWorkspaceService.java

Lines 99 to 104 in 403f315

	if (fileNameStr.endsWith(".bib")) {
	codeLanguageId = "bibtex";
	} else if (fileNameStr.endsWith(".tex")) {
	codeLanguageId = "latex";
	} else if (fileNameStr.endsWith(".md")) {
	codeLanguageId = "markdown";

LTEX-LS should first decide on languageId and if that fails using file extension? But I am curious why codeLanguageId instead of languageId is checked, since the LSP specification does only specify a languageId. The sublime client sends the language id according to the lines in LTEX-LS (on textDocument/didOpen) but LTEX-LS ignores those and uses extension instead.

[valentjn]

Language servers use the language ID of the text document when they “[handle] more than one language to avoid re-interpreting the file extension” (see LSP spec). So LT_EX LS does this as well. Remember that the document URL may just be something like untitled:Untitled-1. You can't guess which language such files would have.

The code you quote is from a function called executeCheckDocumentCommand. This code is only run if the ltex.checkDocument command is executed, so when a manual check is requested by the client by executing this custom command (I think LSP plans to support this natively). codeLanguageId is a custom argument for this custom command; there is no languageId argument in this context (see the linked docs).

LT_EX LS's code tries to distinguish whenever it can between the code language (L^AT_EX, Markdown, etc.) and the (natural) language (English, German, etc.) of the document. Classic language servers deal with only one layer of language, as they usually don't have to bother with natural languages; therefore, this terminology is not present in the LSP spec. When I say code language ID in the following, I mean languageId in terms of the LSP spec.

When a file is checked through the usual way, i.e., automatic checks triggered by textDocument/didOpen and textDocument/didChange, LT_EX LS does use only the code language ID of the document and not the file extension, see LtexTextDocumentService.didOpen and the constructor of LtexTextDocumentItem; the code language ID is ultimately used in DocumentChecker.fragmentizeDocument. If it's not working for you, then maybe you're triggering the checks manually via ltex.checkDocument, or it's a bug in either your client or the server.

Regarding the actual feature request, I'm not sure what the proposed solution should look like. If you tell LT_EX LS that a class/style file is latex via its code language ID, then it will check it like every other L^AT_EX file, so this is obviously working as expected. Do you want to reduce the number of false positives? If yes, which false positives do you mean?

Regarding the second related question, if the code language ID is not latex, then yes, LT_EX LS won't parse L^AT_EX commands. It's fully possible (though unreasonable) to parse a document.tex document as Markdown by setting the code language ID to markdown.

[LDAP]

I may have found the issue in my side. The ST client sends tex as languageId instead of latex when dealing with cls and sty files.

[LDAP]

I found the issue: The ST client indeed sends the languageId tex. This is the valid id according to https://microsoft.github.io/language-server-protocol/specification#textDocumentItem

[valentjn]

I thought the problem of this issue was that there were too many false positives with class and style files (see issue description)? Now it sounds like there were no diagnostics at all due to the language ID mismatch? Can you please clarify what exactly the problem of this issue is, and what the desired solution should look like?

I doubt that we should check class or style files by default, as they usually consist mostly of T_EX code (maybe with a little bit of L^AT_EX in it) with hardly any natural text, e.g., this example. That's why tex is the correct language ID for these files, and that's also why LT_EX doesn't check these, as there would be lots of false positives as LT_EX is not a full T_EX parser. If the goal of this issue (which I don't know) was to enable checking these files, could you give an example class or style file that should be checked?

[LDAP]

It's the languageId mismatch. The false positives were a result of that. In my opinion I would at least allow TeX files to be parsed and not handle the id tex as plain.
The server can be independently disabled by the client for TeX.

[valentjn]

Ok. I'm still not convinced it's a good idea to check these files, but it doesn't hurt to let the client decide by adding "tex" to ltex.enabled.

[valentjn]

Fix released in 11.0.0.