5 ms·

I think it makes sense, if I typed something wrong, I often feel it before I can read it, but if I already pushed enter, being able to ctrl+c within 100 ms is e

by dusted 2y ago

I think it makes sense, if I typed something wrong, I often feel it before I can read it, but if I already pushed enter, being able to ctrl+c within 100 ms is enough to save me. I'm pretty sure I've also aborted git pushes before they touched anything before I put this on, but this makes it more reliable.

SOLAR_FIELDS 2y ago
100 ms is an insanely short window. I would say usually even 1000ms would be too short for me to recognize and kill the command, even if I realized immediately that I had done something wrong.
- jsjshsbd 2y ago
  It's much too short to read an output, interpret it and realize you have to interrupt But often you type something, realize it's wrong while you are typing but not fast enough to stop your hand from pressing [Enter] That is one of the only situation 100ms would be enough to safe you That being said, the reason in the article for 100ms is just confused commander. Why would anyone: 1) encode a Boolean value as 0/1 in a human readable configuration 2) encode a duration as a numeric value without unit in a human readable configuration Both are just lazy
  - Reason077 2y ago
    > "Why would anyone ... encode a Boolean value as 0/1 in a human readable configuration" It may be lazy, but it's very common!
  - grayhatter 2y ago
    laziness is a virtue of a good programmer. why demand many char when few char do trick? also > Why would anyone [...] encode a duration as a numeric value without unit in a human readable configuration If I'm only implementing support for a single unit, why would you expect or want to provide a unit? What's the behavior when you provide a unit instead of a number? > but not doing that extra work is lazy no, because while I'm not implementing unit parsing for a feature I wouldn't use, instead I'm spending that time implementing a better, faster diff algorithm. Or implementing a new protocol with better security, or sleeping. It's not lazy to do something important instead of something irrelevant. And given we're talking about git, which is already very impressive software, provided for free by volunteers, I'm going to default to assuming they're not just lazy.
  - SoftTalker 2y ago
    Absolutely. When I'm booting up an unfamiliar system and trying to catch the BIOS prompt for something non-normal, even 5 seconds is often too short. For me to notice that the prompt has been given, read "PRESS DEL KEY TO ENTER SETUP, F11 FOR BOOT OPTIONS, F12 FOR PXE BOOT" (or whatever), understand it, look for the F11 key on the possibly unfamilar keyboard on my crash cart, and press it, can often take me more than 5 seconds. Especially if it's not a single key required but a control sequence. Maybe I'm slow. I always change these prompts to 10 seconds if they are configurable. Or I'll make a label with the options and stick it on the case so I can be prepared in advance.
Etheryte 2y ago
Maybe worth noting here that 100ms is well under the human reaction time. For context, professional sprinters have been measured to have a reaction time in the ballpark of 160ms, for pretty much everyone else it's higher. And this is only for the reaction, you still need to move your hand, press the keys, etc.
- shawabawa3 2y ago
  In this case the reaction starts before you hit enter, as you're typing the command So, you type `git pshu<enter>` and realise you made a typo before you've finished typing. You can't react fast enough to stop hitting enter but you can absolutely ctrl+c before 100 more ms are up
  - brazzy 2y ago
    > you can absolutely ctrl+c before 100 more ms are up Not gonna believe that without empirical evidence.
    - burnished 2y ago
      I think they are talking about times where you realize a mistake as you are making it as opposed to hindsight, given that 100ms seems pretty reasonable.
      - brazzy 2y ago
        "seems pretty reasonable" is not evidence.
      - dusted 2y ago
        This is exactly what I'm trying to say. The actions are underway by muscles (or _just_ completed) and the brain catches something's off and so ctrl+c is queued.
    - deleted 2y ago
      [deleted]
    - 2y ago
dankwizard 2y ago
Neo, get off HN and go destroy the agents!
frde_me 2y ago
But the point here is not that you need to realize you typed something wrong and then cancel (in that case just don't enable the setting if you always want to abort). The point is that you need to decide if the autocorrect suggestion was the right one. Which you can't know until it tells you what it wants to autocorrect to.
tokai 2y ago
You are talking about an anticipatory response. Human response have been studied extensively and it is broadly accepted that ~100ms is the minimum for physiological processing and motor response to stimuli. If you feel you go faster you are anticipating your reaction.

by dusted 2y ago

SOLAR_FIELDS 2y ago

100 ms is an insanely short window. I would say usually even 1000ms would be too short for me to recognize and kill the command, even if I realized immediately that I had done something wrong.

jsjshsbd 2y ago
It's much too short to read an output, interpret it and realize you have to interrupt But often you type something, realize it's wrong while you are typing but not fast enough to stop your hand from pressing [Enter] That is one of the only situation 100ms would be enough to safe you That being said, the reason in the article for 100ms is just confused commander. Why would anyone: 1) encode a Boolean value as 0/1 in a human readable configuration 2) encode a duration as a numeric value without unit in a human readable configuration Both are just lazy
- Reason077 2y ago
  > "Why would anyone ... encode a Boolean value as 0/1 in a human readable configuration" It may be lazy, but it's very common!
- grayhatter 2y ago
  laziness is a virtue of a good programmer. why demand many char when few char do trick? also > Why would anyone [...] encode a duration as a numeric value without unit in a human readable configuration If I'm only implementing support for a single unit, why would you expect or want to provide a unit? What's the behavior when you provide a unit instead of a number? > but not doing that extra work is lazy no, because while I'm not implementing unit parsing for a feature I wouldn't use, instead I'm spending that time implementing a better, faster diff algorithm. Or implementing a new protocol with better security, or sleeping. It's not lazy to do something important instead of something irrelevant. And given we're talking about git, which is already very impressive software, provided for free by volunteers, I'm going to default to assuming they're not just lazy.
- SoftTalker 2y ago
  Absolutely. When I'm booting up an unfamiliar system and trying to catch the BIOS prompt for something non-normal, even 5 seconds is often too short. For me to notice that the prompt has been given, read "PRESS DEL KEY TO ENTER SETUP, F11 FOR BOOT OPTIONS, F12 FOR PXE BOOT" (or whatever), understand it, look for the F11 key on the possibly unfamilar keyboard on my crash cart, and press it, can often take me more than 5 seconds. Especially if it's not a single key required but a control sequence. Maybe I'm slow. I always change these prompts to 10 seconds if they are configurable. Or I'll make a label with the options and stick it on the case so I can be prepared in advance.

Etheryte 2y ago

Maybe worth noting here that 100ms is well under the human reaction time. For context, professional sprinters have been measured to have a reaction time in the ballpark of 160ms, for pretty much everyone else it's higher. And this is only for the reaction, you still need to move your hand, press the keys, etc.

shawabawa3 2y ago
In this case the reaction starts before you hit enter, as you're typing the command So, you type `git pshu<enter>` and realise you made a typo before you've finished typing. You can't react fast enough to stop hitting enter but you can absolutely ctrl+c before 100 more ms are up
- brazzy 2y ago
  > you can absolutely ctrl+c before 100 more ms are up Not gonna believe that without empirical evidence.
  - burnished 2y ago
    I think they are talking about times where you realize a mistake as you are making it as opposed to hindsight, given that 100ms seems pretty reasonable.
    - brazzy 2y ago
      "seems pretty reasonable" is not evidence.
    - dusted 2y ago
      This is exactly what I'm trying to say. The actions are underway by muscles (or _just_ completed) and the brain catches something's off and so ctrl+c is queued.
  - deleted 2y ago
    [deleted]
  - 2y ago

dankwizard 2y ago

Neo, get off HN and go destroy the agents!

frde_me 2y ago

But the point here is not that you need to realize you typed something wrong and then cancel (in that case just don't enable the setting if you always want to abort). The point is that you need to decide if the autocorrect suggestion was the right one. Which you can't know until it tells you what it wants to autocorrect to.

tokai 2y ago

You are talking about an anticipatory response. Human response have been studied extensively and it is broadly accepted that ~100ms is the minimum for physiological processing and motor response to stimuli. If you feel you go faster you are anticipating your reaction.