Wrong language passed to grammar checkers 'textidot' and 'vlty'

[cristobaltapia]

Description

When trying to use the grammar checkers 'textidot' or 'vlty' an error is displayed, saying that the language is unknown.

Steps to reproduce

I have the following configuration defined:

let g:tex_flavor = 'latex'

let g:vimtex_grammar_vlty = {}
let g:vimtex_grammar_vlty.lt_command = 'languagetool'
let g:vimtex_grammar_vlty.server = 'my'
let g:vimtex_grammar_vlty.show_suggestions = 1
let g:vimtex_grammar_vlty.shell_options =
        \   ' --multi-language'
        \ . ' --packages "*"'
        \ . ' --define ~/vlty/defs.tex'
        \ . ' --replace ~/vlty/repls.txt'
        \ . ' --equation-punctuation display'
        \ . ' --single-letters "i.\,A.\|z.\,B.\|\|"'
        \ . " --lt-options '~--language en-US'"

let g:vimtex_grammar_textidote = {
            \ 'jar': '/opt/textidote/textidote.jar',
            \ 'args': '',
            \}

I define the spell language within the file with a modline:

\documentclass{minimal}
\begin{document}
Hello world!
\end{document}
% vi:spelllang=en_us

Then run e.g.:

compiler textidote | make

Expected behavior

Grammar check

Actual behavior

Errors occur.
Specifically,, textidote throws this error:

:!java -jar '/opt/textidote/textidote.jar' --no-color --output sing
leline --check enUS 'minimal.tex'  2>&1| tee /tmp/nvimIfjg0e/11         
TeXtidote v0.8.2 - A linter for LaTeX documents and others
(C) 2018-2021 Sylvain Hallé - All rights reserved

Unknown language: enUS

and vlty this:

Language 'en' not listed in output of languagetool --list!
Trying 'en' instead.                                                   
Error detected while processing /home/tapia/.vim/plugged/vimtex/compiler/vlty.vim
:
line   90:
:!python3 -m yalafi.shell --lt-command languagetool --server my --encoding utf-8
--language en --disable "WHITESPACE_RULE" --enable "" --disablecategories "" --en
ablecategories "" --documentclass "minimal" --packages ""  --multi-language --pac
kages "*" --define ~/vlty/defs.tex --replace ~/vlty/repls.txt --equation-punctuat
ion display --single-letters "i.\,A.|z.\,B.||" --lt-options '~--language en-US' '
minimal.tex'  2>&1| tee /tmp/nvimIfjg0e/12

*** yalafi.shell: problem:
could not open file "/home/tapia/vlty/repls.txt"

As far as I understand, the correct language in this case should be en_US not enUS nor en-US.

Do you use a latexmkrc file?

no

VimtexInfo

System info
  OS: Arch Linux
  Vim version: NVIM v0.5.1
  Has clientserver: true
  Servername: /tmp/nvimIfjg0e/0

VimTeX project: minimal
  base: minimal.tex
  root: /home/tapia/Documents/latex
  tex: /home/tapia/Documents/latex/minimal.tex
  main parser: current file verified
  document class: minimal
  compiler: latexmk
    engine: -lualatex
    options:
      -verbose
      -shell-escape
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    build_dir: aux-folder
    callback: 0
    continuous: 0
    executable: latexmk
  viewer: Zathura
    xwin id: 0
  qf method: LaTeX logfile

[lervag]

When trying to use the grammar checkers 'textidot' or 'vlty' an error is displayed, saying that the language is unknown.

textidot

I've fixed a minor bug here, please test again now.

vlty

To be honest, I'm no expert on this particular thing. After installing Yalafi and languagetool, I found it worked well when I removed the .server option and the --define and --replace options.

I'll ping the Yalafi dev to see if he has a comment here: @matze-dd

Perhaps there's been changes to languagetool that breaks something? Or simply that we are not configuring things properly?

@Konfekt: You also did some work on vlty.vim, so perhaps you have some relevant experience that may be helpful here?

[cristobaltapia]

@lervag thanks for the quick response! I just tested the fix for textidot and now it is working correctly. vlty is also working for me after changing the configuration as you suggest. So all seems to be working now. I guess I should have tried to understand what those two options (--define and --replace) meant before just copying them in my configuration :P

[Konfekt]

Unknown language: enUS

is fixed by b0798e5

could not open file "/home/tapia/vlty/repls.txt"

seems to be an issue of vlty itself worked around as suggested by @lervag

Language 'en' not listed in output of languagetool --list!
Trying 'en' instead.

The logic of this check was flawed. Above PR should fix it.

Still, it could be that languagetool --list does not work as expected and should be checked.

[cristobaltapia]

Still, it could be that languagetool --list does not work as expected and should be checked.

I think this is the problem. The command languagetool --list throws a java error and opens a window with the languagetool GUI:

languagetool --list
java.io.FileNotFoundException: --list (No such file or directory)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at org.languagetool.gui.Main.loadFile(Main.java:216)
	at org.languagetool.gui.Main.access$2100(Main.java:144)
	at org.languagetool.gui.Main$7.run(Main.java:1204)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I am using Archlinux and languagetool was installed from the repos.

[lervag]

I guess I should have tried to understand what those two options (--define and --replace) meant before just copying them in my configuration :P

Heh, yeah. It's a common mistake :)

Language 'en' not listed in output of languagetool --list!
Trying 'en' instead.

The logic of this check was flawed. Above PR should fix it.

Thanks, I'll look into the PR as soon as possible.

Edit: PR #2191 is merged.

Still, it could be that languagetool --list does not work as expected and should be checked.

I think this is the problem. The command languagetool --list throws a java error and opens a window with the languagetool GUI:

This was already addressed by me in my earlier commit. languagetool --list on itself does not work. However, languagetool --list SOMEFILE works, even if the file argument SOMEFILE does not exist.

[Konfekt]

This was already addressed by me in my earlier commit. languagetool --list on itself does not work. However, languagetool --list SOMEFILE works, even if the file argument SOMEFILE does not exist.

This sounds like an issue with the languagetool wrapper script. One would expect it to behave like java -jar languagetool-commandline.jar.

[lervag]

I agree, but I'm not personally an avid user of languagetool, so I won't address that myself.

[Konfekt]

Oh, well, if languagetool opens a GUI then perhaps it is supposed to do something different from the command-line jar. Perhaps @cristobaltapia could check back with its creator how interchangeable those two commands are.

[cristobaltapia]

I just made a bit of research and found that the problem with the --list argument has already been reported in the Archlinux bug report system[1]. The issue has been without any activity for a year now. I wrote a comment there to ask if there are any updates on the matter.

[1] https://bugs.archlinux.org/task/68079?project=0&order=id&sort=desc&string=languagetool

[Konfekt]

Oh, thank you, @cristobaltapia, and sorry for forgetting that I went down this road a year ago.

[cristobaltapia]

No problem @Konfekt ;) At least the workaround is straightforward, so I guess we can live with it until is fixed upstream.