After troubleshooting pycheckers.py, it looks like the issue is caused by inconsistent use of "ignore_codes" vs "ignored_codes". For example, the relevant CLI arg to pycheckers.py is --ignore-codes. This gets parsed into options.ignored_codes. But that means that update_options_locally() would parse the ignore_codes setting from my .pycheckers file into a new options.ignore_codes key. Similar story for the .pycheckers extra_ignore_codes option.
Although I'm not aware of any bugs related to "enable" vs "enabled", it might be a good time to examine that usage as well.
I propose the present tense "ignore" and "enable" be consistently used and all instances of "ignored" and "enabled" be changed. I don't see any issues that would arise due to "ignore". Regarding "enable", the emacs variable flycheck-pycheckers-enabled-codes would be affected.
I couldn't seem to get the
ignore_codes
setting from my.pycheckers
file to take effect. Example contents:After troubleshooting pycheckers.py, it looks like the issue is caused by inconsistent use of "ignore_codes" vs "ignored_codes". For example, the relevant CLI arg to pycheckers.py is
--ignore-codes
. This gets parsed intooptions.ignored_codes
. But that means that update_options_locally() would parse theignore_codes
setting from my .pycheckers file into a newoptions.ignore_codes
key. Similar story for the .pycheckersextra_ignore_codes
option.Although I'm not aware of any bugs related to "enable" vs "enabled", it might be a good time to examine that usage as well.
I propose the present tense "ignore" and "enable" be consistently used and all instances of "ignored" and "enabled" be changed. I don't see any issues that would arise due to "ignore". Regarding "enable", the emacs variable
flycheck-pycheckers-enabled-codes
would be affected.