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

support for reStructuredText #32

Closed
jaguarfi opened this issue Apr 9, 2020 · 6 comments
Closed

support for reStructuredText #32

jaguarfi opened this issue Apr 9, 2020 · 6 comments
Assignees
Labels
1-feature-request ✨ Issue type: Request for a desirable, nice-to-have feature 3-fixed Issue resolution: Issue has been fixed on the develop branch
Milestone

Comments

@jaguarfi
Copy link

jaguarfi commented Apr 9, 2020

I was wondering whether or not it is possible to support reStructuredText.

@jaguarfi jaguarfi added the 1-feature-request ✨ Issue type: Request for a desirable, nice-to-have feature label Apr 9, 2020
@valentjn
Copy link
Owner

@jaguarfi Thanks for the suggestion. For this, we'd need a Java parser for reStructuredText. The only one that I can find is JRst (see this answer on Stack Overflow and this fork on GitHub), but that hasn't been maintained in ten years. More convoluted solutions would involve calling external programs such as Pandoc, but that would be pretty slow in an editing context.

So unless you know a parser or a better way, the answer to your question is "probably, but it would be pretty difficult."

@valentjn valentjn added the 2-upstream Issue status: Bug is caused by some dependency, might have to wait before continuing label Apr 10, 2020
@valentjn
Copy link
Owner

Closing as this is currently out of scope.

@valentjn valentjn added the 3-out-of-scope Issue resolution: Issue is out of LTeX's feature scope, or fixing this would be too complicated label May 25, 2020
@valentjn
Copy link
Owner

valentjn commented Aug 9, 2020

There's another constraint: We need not only a parser, but one that outputs an AST (abstract syntax tree) with corresponding source code positions. Otherwise, we can't map positions of the LanguageTool error messages back to positions in the original text. Both JRst and Pandoc (see #91) fail to satisfy this constraint.

@valentjn valentjn reopened this Apr 9, 2021
@valentjn valentjn removed 2-upstream Issue status: Bug is caused by some dependency, might have to wait before continuing 3-out-of-scope Issue resolution: Issue is out of LTeX's feature scope, or fixing this would be too complicated labels Apr 9, 2021
@valentjn valentjn self-assigned this Apr 9, 2021
@valentjn valentjn added this to the 10.1.0 milestone Apr 9, 2021
@valentjn
Copy link
Owner

valentjn commented Apr 9, 2021

I'm currently writing a very basic converter/filter myself. It basically strips off all the markup to reduce the number of false positives LanguageTool produces. It's not a parser (reStructuredText is very complex), but I guess it's better than nothing.

Don't get your hopes too high; for example, tables are currently ignored as a whole. Stuff like multi-line cells would lead to non-monotonous text position mapping (text of one multi-line cell continues "after" the text of another multi-line cell), and that would screw up the locations of all the diagnostic messages.

@valentjn
Copy link
Owner

This should be fixed in the next release.

@valentjn valentjn added the 3-fixed Issue resolution: Issue has been fixed on the develop branch label Apr 10, 2021
@valentjn
Copy link
Owner

Fix released in 10.1.0.

me-johnomar added a commit to me-johnomar/ltex-ls that referenced this issue Jan 31, 2024
me-johnomar added a commit to me-johnomar/ltex-ls that referenced this issue Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1-feature-request ✨ Issue type: Request for a desirable, nice-to-have feature 3-fixed Issue resolution: Issue has been fixed on the develop branch
Projects
None yet
Development

No branches or pull requests

2 participants