Add support for checking programming language string literals

[oblitum]

Note: Per the contribution guidelines, deleting parts of the template or not filling in vital information may result in the issue to be immediately closed as invalid.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Using actual real-world examples that explain why you and many other users would benefit from the feature increases the request's chances of being implemented.

Currently I'm sporadically using LT_EX for programming language comments to great effect. If it's done for comments, why not for string literals? I think it would be nice to have as an option.
.
Describe the solution you'd like
A clear and concise description of what you want to happen.

I wish an option to have it enabled/disabled for programming language string literals.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

None

Additional context
Add any other context or screenshots about the feature request here.

#350

[valentjn]

LT_EX is primarily a grammar checker, not only a spell checker. From my experience, only few strings are actual sentences. A lot of strings are not even natural language at all (e.g., vscode-ltex's code contains many i18n keys and SHA hashes as strings), which would generate many false positives. There are already spell checkers for strings, at least for VS Code (not sure about Neovim).

On the other hand, string parsing is non-trivial to implement (e.g., character vectors in MATLAB, template strings in TypeScript, etc.). So the benefit/cost ratio is pretty small here IMO.

Can you please add actual real-world examples (programming languages, example scenarios/strings, etc. for which you would use this) to the feature request, as the template says?

[oblitum]

Hi. TBH, I'm naked at such actual real-world examples, and FWIW, before posting I realized the shortcomings you're describing. I think some were referred to in #350 as well.

I just have one argument over this: LT_EX is a very useful tool, and it's in my machine, it's a lost opportunity not being able to simply toggle it on at some very specific moment when I wish to proofread a document. That's a conscious choice, so I surely realize the effect of the many false positives it can bring, but when doing that I'm generally interested in some specifics of the document, LT_EX even provides the feature of checking a given selection, so I imagine toggling it over some code selection to proofread the strings in it, for example.

Notice the usability here isn't to frame this feature in the same sense as it applies to officially supported filetypes, I surely wouldn't use it always enabled in programming languages, I'd only toggle it when I feel necessary, possibly toggling it off afterwards.

FWIW, I apply almost the same workflow regarding comments proofreading too. I use it on a few occasions, but it's extremely handy to have.

[oblitum]

Notice I don't mean to simply increase the amount of content being checked in programming languages, to add upon comments. Ideally, when enabling LT_EX, in the referred workflow above, it would be best to be able to toggle "check comments" and "check strings" independently.

[oblitum]

I realize the cost for parsing string literals, it's indeed a complicated matter. Please close it if you weight it's too much complexity for not much benefit.

[oblitum]

This made me realize... if supporting many string literal types is non trivial, and given the usecase I just described, what about a feature like: "force check of selection". So you wouldn't have to bother with literals, and I would still be able to reach the tool I have, constraining it to where I wish it to apply, regardless of context (filetype supported or not, comment or not, literal or not, won't matter).

This made realize of the raw language-tool plugins I already have used. Not sure whether ltex could work like them, I didn't check.

[oblitum]

Ah. Sorry the noise!

CocCommand ltex.checkSelection already fulfills this. 😅

[oblitum]

Hmmm, actually my bad, ltex.checkSelection only worked on a scratch file without a filetype (dunno why here it worked as intended). Trying it over some programming language file had no effect, even when it's toggled on for the given filetype, I got all comments checked, but CocCommand ltex.checkSelection over some string literal contents had no effect in checking it, and it actually caused the document checks to be cleared (checkSelection seems to behave as expected only in markdown, latex, etc).

[github-actions]

This issue is now fixed on develop. The fix will be included in the next release of LT_EX.

If you don't want to wait, you can try out the nightly pre-release tomorrow. Nightly pre-releases are published every morning at around 4am UTC.

[valentjn]

Fix released in 13.1.0.