4 ms·
This seems like really quite bad design. EDIT: 1) is the result of my misreading of the article, the "previous value" never existed in git. 1) Pushing a chang
by snet0 2y ago
This seems like really quite bad design.
EDIT: 1) is the result of my misreading of the article, the "previous value" never existed in git.
1) Pushing a change that silently break by reinterpreting a previous configuration value (1=true) as a different value (1=0.100ms confirmation delay) should pretty much always be avoided. Obviously you'd want to clear old values if they existed (maybe this did happen? it's unclear to me), but you also probably want to rename the configuration label..
2) Having `help.autocorrect`'s configuration argument be a time, measured in a non-standard (for most users) unit, is just plainly bad. Give me a boolean to enable, and a decimal to control the confirmation time.
- iab 2y ago“Design” to me intimates an intentional broad-context plan. This is no design, but an organic offshoot
- snet0 2y agoSomeone thought of a feature (i.e. configurable autocorrect confirmation delay) and decided the interface should be identical to an existing feature (i.e. whether autocorrect is enabled). In my thinking, that second part is "design" of the interface.
- iab 2y agoI think that is something that arose from happenstance, not thoughtful intent - this is true because of how confusing the end result is.
- jsnell 2y agoFor point 1, I think you're misunderstanding the timeline. That change happened in 2008, during code review of the initial patch to add that option as a boolean, and before it was ever committed to the main git tree.