💡: Split behavior between case and accents from `--ignore-case` / `--no-ignore-case`

[phansys]

Problem

Currently, these options handle two different cases from a single control point, as if they were synonyms. I need to split the control point to handle these cases separately.

By instance, it is fine for me to admit the term trivy (lowercase variant of Trivy), as it can be used as a command name (trivy image --help), while I can't allow misspelled (nonexistent) terms, like minimo (accepted as valid because mínimo is the correct term from the Spanish dictionary).

Solution

Split case-insensitive behavior between --ignore-case / --no-ignore-case, leaving --ignore-case / --no-ignore-case to handle only the case-insensitive behavior and adding --ignore-accents / --no-ignore-accents to handle the accents omission if needed.

Note: I know that changing the behavior of an existing option is technically a BC break.

Alternatives

Create new options to avoid breaking BC with the behavior change, deprecating the exiting ones or its current behavior.

Additional Context

cspell trace --no-ignore-case "minimo" "trivy"

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[Jason3S]

@phansys,

Thank you for the suggestion.

I need to understand why the current implementation isn't working for you.

There are currently two modes:

• case and accent sensitive - Words must match both case and accents.
• non-(case and accent) sensitive - matching case and accents are optional.

These address two primary use cases:

• Standard writing, where it is important to get spelling right.
• Computer code, where case and accents might interfere with the writing of the code.

What is your usecase?

Since trivy is a valid name for a command lint tool, then it can be added to the software tools dictionary.

In any case, I would rather take a different approach and enable the configuration on a per dictionary basis. That way the coding terms could be in any case and with or without accents while the Spanish terms would be strict.

[phansys]

Thank you for the feedback @Jason3S! I like the idea of having a per dictionary approach for this case. BTW, I have no problem in adding the lowercase variants of the software tools (to cover the CLI invocations for example) if this is the best approach at the moment.

---

My use case

I have a CI job to prevent the custom dictionaries included in my projects to include terms that are already present in built-in dictionaries. For this purpose, I use the following command:

cspell trace --only-found --no-ignore-case ${TERM_LIST};

In this scenario, if the term trivy is added to a custom dictionary, my CI job is not identifying the duplication with the term Trivy declared in the software-terms built-in dictionary.

[rm-arun-kumar]

Hi @Jason3S (I don't want to open a new issue to ask this. So I commenting here.)

How can I add a term that contains spaces to the list of restricted words?

"mail agent"

I can forbid the "mailagent" (without space) word easily via custom dictionary or json config(flagWords).

I wish to stop this particular text from appearing in the user interface as a component of any other text content.

I have tired flagWords , words configs, nothing helps.!

Im using cspell with npx command on en.json file which contains all the text which are appear in UI

Cspell version: 8.19.4