Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] grammar analysis using textidote #1311

Closed
sim590 opened this issue Jan 19, 2019 · 7 comments
Closed

[Feature request] grammar analysis using textidote #1311

sim590 opened this issue Jan 19, 2019 · 7 comments

Comments

@sim590
Copy link

sim590 commented Jan 19, 2019

So, this feature request may appear as premature, but I am posting it in case this could help motivate people to contribute on this. Textidote is a program that interfaces with language tool and preparses (removes) LaTex macros before passing the resulting text to LanguageTool. The final result displays in consistently regarding the initial LaTeX code and appears to be the most viable option (to this day and to the best of my knowledge) to get LaTeX grammar checks.

I have opened an issue on textidote's repository for a feature request that would enable output into parsable format. Once that would be implemented, Vimtex could follow by implementing grammar checks display into the quickfix (or location) window for example.

The only issue I see with implementing the plugin as part of Vimtex is that textidote also supports Markdown. Therefore, the grammar check error displaying plugin may have more sense as standalone. However, I don't think that textidote project will lead to support more languages other than that, so maybe it can still be considered as a LaTex only plugin check anyway if you will.

That being said, a LanguageTool Vim plugin already exists and does a good job of what I'd like to see in Vimtex. However, this plugin interfaces with LanguageTool directly and not with textidote, therefore it cannot support LaTeX.

Consequently, as I see it, the best course of action would be to extract relevant code from the LanguageTool plugin which should be written as a standalone grammar error display plugin (decoupled from LanguageTool or any language checker). Then, make VimTex use that code so that it interfaces with textidote's output.

Finally, I think that this can be reasonably easy to implement, considering the amount of code already existing and doing more or less what we want. That being said, I have not checked how the Vim plugin for LanguageTool works, so maybe the request for textidote to implement a parsable output is not needed at all. I'll have to dig into the plugin.

I'm eager to know what Vimtex's user think about that. I hope this idea appeals to many.

@sim590
Copy link
Author

sim590 commented Jan 19, 2019

I have just taken a look at the Vim plugin for LanguageTool and it does use XML output. Therefore, the feature request I opened on textidote's repository is mandatory if we want to reuse the LanguageTool plugin's code.

@lervag
Copy link
Owner

lervag commented Feb 1, 2019

I am sorry for responding so late! I've been very busy lately. Life and all.

I'm not familiar with LanguageTool. Can you describe (as briefly as possible):

  • What is LanguageTool; how does it work?

  • How would a Vim interface work, exactly? I.e.,

    • which mappings (or commands) should be available?
    • what are the results of performing them?

Other questions:

  • Are you able to outline or start a PR for this feature yourself?

  • In a way, this seems very related to linting in general. Would it perhaps be more appropriate to add this as a specific linter to plugins like ale? Ale already has some linters for LaTeX, see here.

@sim590
Copy link
Author

sim590 commented Feb 2, 2019

I am sorry for responding so late! I've been very busy lately. Life and all.

This is all fine. We are all busy! 😉

I'm not familiar with LanguageTool. Can you describe (as briefly as possible):

  • What is LanguageTool; how does it work?

This is a grammar checking program which reports syntactical and lexical errors in human language (English, French, etc.) on standard output. You pass your text on standard input and LanguageTool reports errors on standard output.

  • How would a Vim interface work, exactly? I.e.,

    • which mappings (or commands) should be available?
    • what are the results of performing them?

This can be presented in Vim in the manner which vim-LanguageTool does. As I said, the final result would essentially be a the same as vim-LanguageTool, but using textidote as a backend.

Other questions:

  • Are you able to outline or start a PR for this feature yourself?

Yes. I'm waiting for XML output feature request to arrive for textidote before working on it. If I have the time, I may contribute to textidote myself to add XML output feature, but I'm presently not very much available.

  • In a way, this seems very related to linting in general. Would it perhaps be more appropriate to add this as a specific linter to plugins like ale? Ale already has some linters for LaTeX, see here.

I'm not sure how this would fit. From what I understand, ale is more for computer language linting while textidote and LanguageTool are for human language grammar (English, French, etc.).

@lervag
Copy link
Owner

lervag commented Feb 3, 2019

I'm not sure how this would fit. From what I understand, ale is more for computer language linting while textidote and LanguageTool are for human language grammar (English, French, etc.).

Actually, this is not quite right. Ale is more general purpose. It defines an interface to Vim for linting, where the actual linter may be of any kind. If you see the supported languages and tools section in the LaTeX and Markdown rows, you will find support for e.g. proselint and redpen, both of which are human language linters.

As such, I feel more and more convinced that your feature request should rather focus towards e.g. Ale and Neomake.

Feel free to convince me I'm wrong, though! In any case, as you yourself writes, the first step is to make an interface between textidote and XML output, and then an interface to parse this in Vim. This work is relevant regardless of where the end result belongs.

@lervag
Copy link
Owner

lervag commented Feb 22, 2019

As I've not been convinced otherwise, I'll take the liberty of closing this one.

@lervag lervag closed this as completed Feb 22, 2019
@matze-dd
Copy link
Contributor

matze-dd commented May 1, 2020

Hi,

may I draw your attention to the project YaLafi? This is a LaTeX filter suitable for integration with an editor and a proofreading software like LanguageTool. Initially, filtering has been based on recursive regular expressions (project Tex2txt), but now it uses a more powerful scanner / parser for LaTeX analysis.

As other tools like TeXtidote and vscode-ltex, YaLafi provides mapping of character positions between the LaTeX text and the plain text seen by the proofreading tool. Therefore, messages from the proofreader can be properly related to the corresponding parts of the LaTeX text. The current status is that it can be used with Vim plug-in vim-grammarous (see here) and Emacs plug-in Emacs-langtool (see here).

I do my own LaTeX writing with "plain Vim", in a rather simple, Bash-script based environment. The above filter project grew out of the desire to use LanguageTool for the check of already existent LaTeX document trees. Therefore, I wanted to make it flexible and not to produce too many false positives from the proofreading tool. Now it is in a status that one might use it in a larger framework.

Would it be worth to put some effort into integrating YaLafi with vimtex and vim-grammarous? In order to keep things simple for the user, application via Docker seems sensible to me (combined usage of Java, Python, LanguageTool, Vim, ... and of course LaTeX).

Matthias

@lervag
Copy link
Owner

lervag commented May 2, 2020

Thanks, Matthias, for pitching your thoughts on this. Let's continue this at #1684 - I'll give my comments when I get the time to consider it in more depth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants