For settings files I always have an example file with sensible values filled in and along with descriptive keys that serves as reasonable documentation. If something is truly unknowable, I’ve probably done something wrong.
brettvitaz
Agreed. Except that it’s not easier to write imo
Every time I have reached for TOML I have ended up using JSON. The first reason is that Python standard library can read but not write TOML, which is generally useless for me. The second reason is TOML does not add any benefit over JSON. It’s not that much easier to read and IMO JSON is easier to write by hand because the syntax rules are completely obvious.
Animated? Scavenger’s Reign. (I know, you didn’t ask me) I really liked Blue Eyed Samurai until about half way through and then the ending of the season had me wondering what the writers were thinking. Characters motivations stopped making sense.
This print has Z-hop enabled and the bed moves out of the way when switching tools, and you’re seeing that occasionally.
Your cat is adorable
This article was more interesting than its headline would suggest.
This summary is missing tons of context and most of the useful information. It’s a poor summary at best and doesn’t really reflect the overall message of the article.
Too low (nozzle height)
In my opinion, the settings file isn’t where this information should be presented. I would put these notes in the release log and readme and example settings file. I have also written this information to logging during startup so a user knows what to do, or I write a migration that does the change automatically if that’s possible.
This is only my opinion and you can use the comment method described like
“//“: “Deprecated”
if desired.