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

Ignore MyST syntax labels #667

Open
1 task done
stevepiercy opened this issue Aug 13, 2023 · 4 comments
Open
1 task done

Ignore MyST syntax labels #667

stevepiercy opened this issue Aug 13, 2023 · 4 comments

Comments

@stevepiercy
Copy link

Check for existing issues

  • Completed

Describe the feature

In my accept.txt, I have a regular expression that I expect to match labels in MyST markup. I also have proper nouns, such as Plone and Volto.

accept.txt

Plone
Volto
^(.*-label)=$

Here is an example label.

(contributing-volto-sign-and-return-the-plone-contributor-agreement-label)=

Here is my regular expression demo:

https://regex101.com/r/MqBJoC/1

When proper nouns appear lower-cased in the labels, Vale returns errors.

 36:15   error       Use 'Volto' instead of          Vale.Terms             
                     'volto'.                                               
 36:41   error       Use 'Plone' instead of          Vale.Terms             
                     'plone'.                                         

If I remove the proper nouns from accept.txt, then the terms Volto and Plone are flagged as misspellings everywhere except in the labels. I also get the exact same result when I also remove the regular expression from accept.txt.

It seems that my only option is to use proper casing in labels. I would like to avoid the work of changing all of our MyST labels. Is this possible?

@jdkato
Copy link
Member

jdkato commented Aug 15, 2023

This is an issue because MyST is not one of Vale's supported formats. As a result, your options are limited (most of Vale's scope-related features will not work) but you could do this:

\sPlone\s
\sVolto\s

This will generally only flag instances that occur in a "prose-like" context. In any case, I'd say that your expectations when using Vale with unsupported formats should be fairly low when it comes to ignoring markup.

@stevepiercy
Copy link
Author

Thanks for the suggestion. In accept.txt, I tried replacing:

Plone
Volto

with

\sPlone\s
\sVolto\s

but that generated over 600 additional errors. Here's example source and result:

- `mywebsite.com-volto` starts the Node.js process that's responsible for Volto {term}`server-side rendering`.
 57:75  error  Did you really mean 'Volto'?  Vale.Spelling 

It appears that this kind of regular expression is not supported in our custom accept.txt. It supports Plone[a-z]{4} and accepts Plonetest.

Aha! This worked:

-{0,1}plone-{0,1}
-{0,1}vlone-{0,1}

There's more than one way to skin a regular expression!

I am still concerned that neither of our earlier regexes worked. Should I keep this issue open or close it?

@jdkato
Copy link
Member

jdkato commented Aug 15, 2023

but that generated over 600 additional errors. Here's example source and result ...

Ah, it likely "solved" the issue with Vale.Terms but caused another one with Vale.Spelling.

I would say that what we're doing here is generally a misuse of vocabulary files: they're designed to work with supported markup formats, not workaround false positives caused by unrecognized ones.

The real solution here would be to add support for MyST, but I can't put a timetable on that.

@stevepiercy
Copy link
Author

Thanks for the explanation. I'm happy to help bring MyST support to Vale to the best of my ability. A cursory look at support for reStructuredText as an example to adapt for MyST was over my head.

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

No branches or pull requests

2 participants