kmk_firmware
kmk_firmware copied to clipboard
KMKfw
add docs/doc_tools for spell checking markdown
This requires aspell be installed and on your path. Right now it's an interactive tool for cleaning up the docs, but it could be adapted to be a commit hook or GitHub action.
Well, I was just about to bring up words that don't exist, but you clearly know the tool. I like this.
This is the tooling I used for #418, and the wordlist is seeded w/ all the words (and a lot of non-words) that I needed to accept in the process of that work.
Looks good to me. I made a comment about a make arg, and that would apply to any tool like these.
Added a make command, cleaned up the bash script, and edited a few more markdown files so make spellcheck can pass without adding anything too questionable to the spelling dictionary.
Any suggestions on whether there'd be a better place to put the script and dictionary? The /docs/docs_utils path was sort of a placeholder, and I'm not really happy with it. Would these files make sense in /util?
Util is historically where we put any tooling that we didn't know where else to put it. That seems reasonable.
I'm ready to call this done. Could maybe add a note about this in docs/contributing.md, but I'm not sure what to say there.
Made a few more edits to the docs along the lines of #418 because if I'm going to commit a new test, I should make the test pass. That being said, I did not add make spellcheck to make test since there is an external non-python dependency.
I was just thinking about this PR a little more: This tooling was quite helpful to me well proofreading the docs. I submitted this PR since there were some interest in it. TBH, i'm not sure it belongs as part of the project. It would be nice if there was a tool like Black that was python native and available from pip. As it is, this feels like scope creep. Maybe it's best to close this or move it back to a draft?
I like it as even an optional tool. It'll be there for those that want to use it, but it won't be a hard requirement like black. Thoughts?
Yeah, that's fine too. If a better tool emerges there's no problem with changing.
I was just thinking about this PR a little more: This tooling was quite helpful to me well proofreading the docs. I submitted this PR since there were some interest in it. TBH, i'm not sure it belongs as part of the project. It would be nice if there was a tool like Black that was python native and available from
pip. As it is, this feels like scope creep. Maybe it's best to close this or move it back to a draft?
There is no reason a tool must be written in Python to be a dev-time dep of KMK. Hell, I stray away from Python stuff these days myself; I'm certainly no purist for the cause. I'm very much a fan of this idea; going to review the PR as-written and provide inline comments as/if appropriate.
As @klardotsh seems to have opinions, if possible, could it be adopted so this can get handled properly?
