flagWords doesn't override minWordLength

[Maxim-Mazurok]

Info

Kind of Issue

• runtime - command-line tools
• building / compiling
• security
• change in behavior
• crash / error

Which Tool or library

• cspell -- the command-line spelling tool
• cspell-tools -- used for building dictionary files
• cspell-lib -- library that does the actual spell checking.
• cspell-trie -- tool for working with trie files.

Which Version

Version: 5.6.6

Issue with supporting library?

• No
• cspell-glob -- library for matching glob patterns
• cspell-io -- thin file i/o library
• cspell-trie-lib - trie lib
• cspell-trie2-lib - trie lib alternate format

OS:

• Macos
• Linux
• Windows
• Other

version:

Ubuntu 20.04.3 LTS
Windows 10

Bug Description

Describe the bug

I've used example config: https://github.com/streetsidesoftware/cspell/tree/main/packages/cspell#example-cspelljson-file
And it doesn't flag "hte" word, or any other 3 letter words that I explicitly want to flag, because only 4+ letter words are being checked, according to the default minWordLength flag.
From the example, I and my colleague assumed that it'll let us flag words of any length. It literally says "flagWords - list of words to be always considered incorrect".

$ cspell trace hte
hte - [words]              From Settings `words` and `userWords`
hte - [ignoreWords]        From Settings `ignoreWords`
hte * [flagWords]          From Settings `flagWords`

To Reproduce

Steps to reproduce the behavior:

1. Use example config: https://github.com/streetsidesoftware/cspell/tree/main/packages/cspell#example-cspelljson-file
2. Create file file.txt with word "hte" in it
3. Run cspell file.txt
4. See that "hte" isn't flagged

Expected behavior

I expect that flagWords will always be flagged as incorrect, no matter the minWordLength. So in the example above, "hte" should be flagged as incorrect.

Screenshots

cspell.json

{
	"version": "0.2",
	"language": "en",
	"flagWords": ["hte"]
}

[Jason3S]

@Maxim-Mazurok,

Great example. Thank you.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.