FR: Autocorrect should ignore "Extra Auto-Correct Source Files"

[jjspace]

Is Your Feature Request Related to a Problem? Please Describe.

The auto-correct rule has an option to specify a file of custom words instead of (or in addition to) the builtin list of words. However if you run the linter on this file it switches all the "word to find" words with the replaced version which inherently removes that configuration in the first place. I have lint on ctrl+s and a muscle memory to just hit this after making changes to a file and didn't realize it was undoing my word list at first.

Describe the Solution You'd Like

The auto-correct rule should be completely skipped on any files that are set for Extra Auto-Correct Source Files. Or if it's not too much more complicated then it should ignore the table of words it's going to pull from to not destroy it's own configuration.

[pjkaufman]

Hey @jjspace . Thanks for the input. Could you explain why the current ways of ignoring a file or turning off linting for a part of file (ranged ignored) are not adequate to handle this scenario?

If the intent is to have this automatic, would it make sense to just auto-ignore these files?

Ignoring for a single rule is not how the logic is designed at this time unless you use the disabled key in the YAML. It is theoretically possible to ignore a single rule if they are one of the files that are storing the configuration for extra auto-correct words, but unless it is well documented this will likely confuse people. Could you explain how you would propose that the user be informed of the fact that the files that are in the list would only have auto-correct mispellings disabled automatically?

Thanks for helping me think through this.

[jjspace]

Could you explain why the current ways of ignoring a file or turning off linting for a part of file (ranged ignored) are not adequate to handle this scenario?

I didn't realize that there was a setting to ignore files, I'm sure others will miss that too. Even with that what if I want to use the other rules, like updating the properties for last edited date and stuff? I don't want to completely ignore the file. The ranged ignore could work but what if I want it to still autoformat the table? But in general, why should it require the user to take extra actions to prevent the rule from breaking in the first place?

If the intent is to have this automatic, would it make sense to just auto-ignore these files?

This would be a way to do it, I think the best way would be to ignore those specific files from specifically this rule. I think in the larger context this whole "create a table in a file somewhere" feels like abusing the system a little bit. This sort of configuration should live in the settings itself but that's probably a much larger change

Ignoring for a single rule is not how the logic is designed at this time unless you use the disabled key in the YAML

It sounds like the logic to ignore a single rule for a specific file is already implemented, I think this would just be forced on for the auto-correct rule on these specific files?

Could you explain how you would propose that the user be informed of the fact that the files that are in the list would only have auto-correct mispellings disabled automatically?

I think adding a single extra line under the "Extra ... Files" setting that says something like this would be enough:

These are files that have a markdown table in them that have the initial word and the word to correct it to (these are case insensitive corrections). Note: the tables used should have the starting and ending | indicators present for each line. Files included in this list will not have auto-correct applied to them.

[pjkaufman]

Could you explain why the current ways of ignoring a file or turning off linting for a part of file (ranged ignored) are not adequate to handle this scenario?

I didn't realize that there was a setting to ignore files, I'm sure others will miss that too. Even with that what if I want to use the other rules, like updating the properties for last edited date and stuff? I don't want to completely ignore the file. The ranged ignore could work but what if I want it to still autoformat the table? But in general, why should it require the user to take extra actions to prevent the rule from breaking in the first place?

The main issue with doing something without the user knowing is that it should be obvious that the change would apply. Since there is no current way to ignore a specific rule for a specific file minus what is done in the frontmatter for rules being disabled it does not seem intuitive to me that a user would expect the rule to be auto disabled for the files as that would imply that the Linter may be doing the same for other files which is false. That is the main reason, beyond assuming users would store these files in a location that would not be linted/would be ignored by the Linter like templates. I am not opposed to doing it in this case so long as users are made aware of this change.

If the intent is to have this automatic, would it make sense to just auto-ignore these files?

This would be a way to do it, I think the best way would be to ignore those specific files from specifically this rule. I think in the larger context this whole "create a table in a file somewhere" feels like abusing the system a little bit. This sort of configuration should live in the settings itself but that's probably a much larger change

While I do agree to some extent that this feature would be nice to ingrain in the settings themselves, it was specifically asked that the custom auto-correct values be kept in a file in the vault. This allows users to better handle what rules they want disabled versus enabled by handling versioning and other more complex setups on their own. At this point, it would be a breaking change to change this which I am not necessarily opposed to doing, but I would want more than 1 opinion on this if a change were to be made to make this easier for users.

Ignoring for a single rule is not how the logic is designed at this time unless you use the disabled key in the YAML

It sounds like the logic to ignore a single rule for a specific file is already implemented, I think this would just be forced on for the auto-correct rule on these specific files?

That is not entirely true. In concept, it exists. However it is never auto-on because that would lead to confusion as to which rules are on and which are off for certain files. That is why I much prefer that the user specify the value in the YAML that they want the rule disabled for the file (better yet would be to list them like templates and add them to the ignored folder/file list). But if there is a good enough way to make this clear and obvious to the users, I am not opposed to auto turning off the auto-correct rule for these config files.

Could you explain how you would propose that the user be informed of the fact that the files that are in the list would only have auto-correct mispellings disabled automatically?

I think adding a single extra line under the "Extra ... Files" setting that says something like this would be enough:

These are files that have a markdown table in them that have the initial word and the word to correct it to (these are case insensitive corrections). Note: the tables used should have the starting and ending | indicators present for each line. Files included in this list will not have auto-correct applied to them.

This proposal is possible. I would likely need to include that text in yellow since it is a warning to users. But it could be added.