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 words define/declared outside the project #3243

Open
Nahor opened this issue May 7, 2024 · 2 comments
Open

Ignore words define/declared outside the project #3243

Nahor opened this issue May 7, 2024 · 2 comments

Comments

@Nahor
Copy link

Nahor commented May 7, 2024

Assuming it's possible, it would be great if the extension could query the language server to check if an unknown word matches an entity declared/defined outside the project (system headers, Rust crates, NPM packages, ...). This would help automatically ignore words that are created by third-party libraries and remove the tedium to ignore the same words over and over just because a library is popular and used in a lot of different projects.

There would be 3 states:

  • disable (current behavior)
  • add to words list
  • add to ignore list

Maybe also add an action to get both lists so a developer could add those words to dictionaries/configuration files and be ignored when running cspell checks without the language server

@JesseRap
Copy link

I recently started using this extension, and I strongly agree.

Is this the same root issue as in this Issue? #3205

Intuitively, we should be allowed to configure the Spell Checker to ignore an unknown word if it is a named parameter of a third-party library function, or if it is the name of a function or method in a third-party library. VS Code is already able to "know" this - incorporating this capacity into the extension would make it much easier to use, and not require ad hoc ignoring of certain lines or adding words to the dictionary.

@Nahor
Copy link
Author

Nahor commented May 25, 2024

Indeed, those two issues have the same end goal. Thanks for pointing it out.

In my opinion though, my proposed solution is more generic (it doesn't rely on external tools, nor is limited to installed libraries) and more dynamic (i.e. update automatically when new/updated libraries).
I also think the solution in #3205 would work better as an third-party tool, which could then also be used outside vscode.

So I'll leave this issue opened and let the maintainers choose which one to close a duplicate of the other.

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

2 participants