Consider renaming the `code` dictionary to `noncode`

[skangas]

Please consider renaming the code dictionary to noncode or similar. The current name makes it sounds like you would want to run the dictionary on code. However, the opposite is the case. I think that could be easier to understand if that was reflected more clearly in the name.

The old name could still be supported as an alias, for backwards-compatibility.

[peternewman]

I think it matches the naming of the other dictionaries currently:

codespell/codespell_lib/_codespell.py

Lines 56 to 110 in a7d80cf

	("clear", "for unambiguous errors", "", False, None, supported_languages_en, None),
	(
	"rare",
	"for rare (but valid) words that are likely to be errors",
	"_rare", # noqa: E501
	None,
	None,
	None,
	None,
	),
	(
	"informal",
	"for making informal words more formal",
	"_informal",
	True,
	True,
	supported_languages_en,
	supported_languages_en,
	),
	(
	"usage",
	"for replacing phrasing with recommended terms",
	"_usage",
	None,
	None,
	None,
	None,
	),
	(
	"code",
	"for words from code and/or mathematics that are likely to be typos in other contexts (such as uint)", # noqa: E501
	"_code",
	None,
	None,
	None,
	None,
	),
	(
	"names",
	"for valid proper names that might be typos",
	"_names",
	None,
	None,
	None,
	None,
	),
	(
	"en-GB_to_en-US",
	"for corrections from en-GB to en-US",
	"_en-GB_to_en-US", # noqa: E501
	True,
	True,
	("en_GB",),
	("en_US",),
	),

Consider names and informal, which contain lists of names and informal terms in the same way as this contains a list of code.

We've also got the description which I think lays out fairly clearly its purpose, but PRs welcome to improve on that...

[skangas]

I use informal to fix informal typos, rare to fix rare ones, usage to fix usage ones.

So should I use code typos to fix code typos? No, I must not do that. This is the inconsistency I see.

(I also shouldn't use name to fix name typos, so perhaps that one should be renamed too. But I don't have any good ideas, and it seems to be a separate issue.)

[DimitriPapadopoulos]

I think part of the reason I have been having a hard time understanding codespell, is that the usual logic is inverted, it contains lists of typos instead of dictionaries of words correctly spelled. On top of that, it's true that names and options are indeed inconsistent:

• dictionary.txt is a list of misspelled words
• dictionary_code.txt is a list of misspelled words, that are often valid words in the context of code (like spawne)
• dictionary_rare.txt is a list of valid words, that are rare enough to often be actual typos when used
• dictionary_informal.txt is a list of valid informal words, that should not be used in written text
• dictionary_usage.txt is a list of valid offensive words, that should be replaced by inclusive words

While I agree dictionary_code.txt may be seen as inconsistent with dictionary_rare.txt, dictionary_informal.txt, dictionary_usage.txt it does seem consistent with dictionary.txt. I have been unable to find a way to name all these files in a logic and consistent way.

I would rather keep thinking about the logic of codespell and how it uses the lists of words/typos, until I find the logic behind it and come up with a global plan to revisit all dictionary names and option names.

[skangas]

While I agree dictionary_code.txt may be seen as inconsistent with dictionary_rare.txt, dictionary_informal.txt, dictionary_usage.txt it does seem consistent with dictionary.txt. I have been unable to find a way to name all these files in a logic and consistent way.

Thanks for taking the time to write up a thoughtful reply.

I don't think I see how it is consistent with dictionary.txt. That file is actually selected for use with the clear keyword. So by that logic, it should be used to fix typos that are, well, "clear" (as opposed to, for example, "non-clear").

But code should not be used to fix "code" typos. It should only be used to fix typos in any type of file that is not code, in other words "non-code" typos.

That still seems inconsistent to me.

I would rather keep thinking about the logic of codespell and how it uses the lists of words/typos, until I find the logic behind it and come up with a global plan to revisit all dictionary names and option names.

This plan makes sense to me. Meanwhile, I still hope that the inconsistency reported here could be fixed. ;-)

[DimitriPapadopoulos]

I think I understand better now. This has to do with option --builtin:

  --builtin BUILTIN-LIST
                        comma-separated list of builtin dictionaries to include (when "-D -" or no "-D" is passed). Current
                        options are:
                        - 'clear' for unambiguous errors
                        - 'rare' for rare (but valid) words that are likely to be errors
                        - 'informal' for making informal words more formal
                        - 'usage' for replacing phrasing with recommended terms
                        - 'code' for words from code and/or mathematics that are likely to be typos in other contexts (such as
                          uint)
                        - 'names' for valid proper names that might be typos
                        - 'en-GB_to_en-US' for corrections from en-GB to en-US
                        The default is 'clear,rare'.

By the way, --builtin BUILTIN-LIST should be changed to --builtin BUILTIN-DICTIONARY for consistency, shouldn't it?

[DimitriPapadopoulos]

• clear will fix clearly invalid words
• code will fix invalid words, that are widely used system function names, and hence valid in the context of source code, so in a sense it will fix “code” words that are valid only in source code
• rare, informal, usage will fix valid words, either because these rare words are often misused, or because we don't want them for different reasons

I do understand why you feel code can be misleading, but I am not certain noncode will make it easier for me to understand. There is some kind of "inverted" logic (I cannot find a better now right now) throughout codespell that keeps disturbing me, but noncode will not help me understand better.

[skangas]

I do understand why you feel code can be misleading, but I am not certain noncode will make it easier for me to understand. There is some kind of "inverted" logic (I cannot find a better now right now) throughout codespell that keeps disturbing me, but noncode will not help me understand better.

Indeed, there's obviously merit to both sides of the argument here. There is also a very understandable reluctance to change something that risks not being a marked improvement.

It's fine to close this issue, or leave it open to see if anyone else has anything to add, as you prefer.

Thanks.

[peternewman]

By the way, --builtin BUILTIN-LIST should be changed to --builtin BUILTIN-DICTIONARY for consistency, shouldn't it?

I think the idea was to represent the fact there can be multiple dictionaries passed in, but there's probably a better way to represent that.

I think really the way to think about it, or the built in dictionaries, is which sets of words to ignore.

Clear should only contain genuine typos, anything that's a typo for someone should get moved/hidden into another dictionary. Hence clear is the base dictionary and should be ignored and almost shouldn't be possible to be disabled.

Hence really he option should be to disable dictionaries rather than enable them (although that then falls apart with custom dictionaries so perhaps that should be another option).

So if I was writing about British History I'd want to use all the dictionaries except:

• en-GB_to_en-US - because I'm writing in British English
• rare - because I might be using archaic words e.g. chancel->cancel
• names - because I'm likely to have lots of names

Consider as a thought experiment (sorry for the rubbish examples and the fact they overlap, but hopefully they prove the point), if we added a medical dictionary with:
platelet->palette

And an art one with:
paint->pant

If I was writing about medical stuff, I'd use all except my new medical dictionary (and maybe names).

If I was writing some art based code, I'd use all except:

• code - because I'm writing code
• art - because I'm using art terms

Unfortunately there has to be a limit to this, in my particular case I've got the domain-specific abbreviation ACN (acn->can) but I don't think we can subdivide indefinitely hence there is the ignore word list at that point to strike individual words from a dictionary.

Or to put it another way the dictionary is just a bulk way to ignore a load of words.

[DimitriPapadopoulos]

In that case, dictionary_code.txt sounds OK: it is just a bunch of “code” words, in the sense that they are valid in the context of source code.

I am still feeling uncomfortable with the “negative” logic of codespell from time to time. In this case, because the core action in codespell is finding/fixing typos, I think I would expect in dictionary_code.txt words that I want to find/fix in source code, not words I do not want to find/fix in source code. But again, I get it.