5 ms·

> Which was what the setting value was changed to in the patch that was eventually accepted. This means that setting help.autocorrect to 1 logically means "wait

> Which was what the setting value was changed to in the patch that was eventually accepted. This means that setting help.autocorrect to 1 logically means "wait 100ms (1 decisecond) before continuing". The mistake was here. Instead of retargeting the existing setting for a different meaning, they should have added a new setting. help.autocorrect - enable or disable help.autocorrect.milliseconds - how long to wait There are similar mistakes in other systems, e.g., MySQL has innodb_flush_log_at_trx_commit which can be 0 if disabled, 1 if enabled, and 2 was added as something special.

stouset 2y ago
The “real” issue is an untyped configuration language which tries to guess at what you actually meant by 1. They’re tripling down on this by making 1 a Boolean true but other integers be deciseconds. This is the same questionable logic behind YAML’s infamous “no” == false.
- Dylan16807 2y ago
  I'd say the new addition is more of a special case of rounding than it is messing up types.
  - stouset 2y ago
    1 was also accepted as a Boolean true in this context, and it still is in other contexts.
    - Dylan16807 2y ago
      > 1 was also accepted as a Boolean true in this context, and it still is in other contexts. Is "was" before the change described at the end of the article, or after it? Before the change, any positive number implied that the feature is on, because that's the only thing that makes sense. After the change, you could say that 1 stops being treated as a number, but it's simpler to say it's still being treated as a number and is getting rounded down. The interpretation of various types is still messy, but it didn't get more messy.
      - stouset 2y ago
        In an earlier iteration the configuration value was Boolean true/false. A 1 was interpreted as true. They changed it to an integral value. This is the entire setup for the problem in the article. Elsewhere, 1 is still allowed as a true equivalent.
        Dylan16807 2y ago
        But then they made it not be a boolean when they added the delay. They went the opposite direction and it caused problems. How is this a situation of "tripling down"? It seems to me like they couldn't make up their mind.
        stouset 2y ago
        The only reason they even need this further hack is because people can reasonably assume that 1 is bool. Now, because of this confusion, they’re special-casing 1 to actually mean 0. But other integers are still themselves. They’ve also now added logic to make "yes", "no", "true", "off“ strings be interpreted as booleans now too.
- JBiserkov 2y ago
  NO is the country code for Norway.
  - xnorswap 2y ago
    "The Norway Problem": https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
smaudet 2y ago
Not sure where the best place to mention would be, but 0.1 deciseconds is not unreasonable, either...yes fastest recorded random reaction time maybe 1.5 ds (coincidentally this is the average gamer reaction time), however non-random reaction times can be much faster (e.g. on a beat). So if you wanted to go that fast, you could, the invokation should have relatively stable speeds (order of some milliseconds...

stouset 2y ago

The “real” issue is an untyped configuration language which tries to guess at what you actually meant by 1. They’re tripling down on this by making 1 a Boolean true but other integers be deciseconds. This is the same questionable logic behind YAML’s infamous “no” == false.

Dylan16807 2y ago
I'd say the new addition is more of a special case of rounding than it is messing up types.
- stouset 2y ago
  1 was also accepted as a Boolean true in this context, and it still is in other contexts.
  - Dylan16807 2y ago
    > 1 was also accepted as a Boolean true in this context, and it still is in other contexts. Is "was" before the change described at the end of the article, or after it? Before the change, any positive number implied that the feature is on, because that's the only thing that makes sense. After the change, you could say that 1 stops being treated as a number, but it's simpler to say it's still being treated as a number and is getting rounded down. The interpretation of various types is still messy, but it didn't get more messy.
    - stouset 2y ago
      In an earlier iteration the configuration value was Boolean true/false. A 1 was interpreted as true. They changed it to an integral value. This is the entire setup for the problem in the article. Elsewhere, 1 is still allowed as a true equivalent.
      - Dylan16807 2y ago
        But then they made it not be a boolean when they added the delay. They went the opposite direction and it caused problems. How is this a situation of "tripling down"? It seems to me like they couldn't make up their mind.
        stouset 2y ago
        The only reason they even need this further hack is because people can reasonably assume that 1 is bool. Now, because of this confusion, they’re special-casing 1 to actually mean 0. But other integers are still themselves. They’ve also now added logic to make "yes", "no", "true", "off“ strings be interpreted as booleans now too.
JBiserkov 2y ago
NO is the country code for Norway.
- xnorswap 2y ago
  "The Norway Problem": https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/

smaudet 2y ago

Not sure where the best place to mention would be, but 0.1 deciseconds is not unreasonable, either...yes fastest recorded random reaction time maybe 1.5 ds (coincidentally this is the average gamer reaction time), however non-random reaction times can be much faster (e.g. on a beat). So if you wanted to go that fast, you could, the invokation should have relatively stable speeds (order of some milliseconds...