Allow abbreviations (and/or support extend-words on command-line)

[neiljp]

Typos works very well on many strings and variable names, and picks up useful changes in eg. test strings or variables 👍

Many of my current file excludes could be better handled under #316 (exclude specific line):

• intentional wrong text in test cases
• date-time strings with timezones that look like words
• external product references (iterm2 != term/item/...) in documentation
• seemingly valid abbreviations, eg. 2nd

Compared to a proper noun like iterm, 2nd seems like this should (almost?) always be a valid word (number/word abbreviation), but I'm not sure if there's a current easy solution for fix 'nd' to 'and' unless it's '2nd' or similar.

There are existing workarounds of adding the word via the toml file or excluding the file entirely, or later using #316 - or expanding the word, though 1st, 3rd, etc are fine. Currently I'm trying to limit excludes as much as possible, though avoiding a toml file until pyproject.toml is supported (#361) by using --exclude <file>.

Resulting questions:

• Can typos allow 2nd, while fixing/recommending nd->and?
• What do you think about allowing extra words via the command-line? (ie. extend file support to args)

[epage]

Please see #466 which is the issue for 2nd. Closing in favor of that one.

[neiljp]

Thanks for reading and triaging!

If the argument feature is not planned, I'd suggest noting in the reference?

[epage]

If the argument feature is not planned, I'd suggest noting in the reference?

To confirm, you are suggesting we should put it in the reference that we won't be support extended the words on the command-line? I'm a bit unclear on this because it seems like getting into the business of document what we don't support is quite open ended.

[neiljp]

My take-away from 'not planned' is that this is outside of the planned project scope.

So yes, if it is considered outside the planned scope to support extending words on the command line, I'd suggest marking the related box in the reference doc with an appropriate note (footnote). That would avoid someone opening another issue, and direct people to using a config file instead.

I agree documenting what won't-be/isn't-yet supported is open-ended in general, unless there is a pattern, in which case docs can help users and maintainers alike :)

[epage]

So you assumed the reference - fields were meant as "not yet or unsupported, unclear"?

For me, it is the opposite,. I read a table like that and I assume it is not intended to be supported unless there is a footnote and requesting it be supported would need some motivation to it. Otherwise, it would have been implemented in the first place.