Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

221–230 of 248 posts

Re: Why is Git Autocorrect too fast for Formula One drivers?

#221

> Originally, if you typed an unknown command, it would just say "this is not a git command". Back in the 70s, Hal Finney was writing a BASIC interpreter to fit in 2K of ROM on the Mattel Intellivision system. This meant every byte was precious. To report a syntax error, he shortened the message for all errors to: EH? I still laugh about that. He was quite proud of it.

ed (the standard editor) optimises that by a further 66.7%.

https://www.gnu.org/fun/jokes/ed-msg.html>

Re: Why is Git Autocorrect too fast for Formula One drivers?

#222
post #179
post #54

Earlier quoted context omitted.

That's what isatty() is for. If stdin is not a TTY, prompting should not be the default. Many programs change their defaults or their entire behavior based on isatty().

isatty() is spoofed in e.g. Make via PTYs. It's a light check at best and lies to you at worst.

If make is going to spoof the PTY, it should take responsibility for answering the autocorrect prompt

Re: Why is Git Autocorrect too fast for Formula One drivers?

#224

IMHO this is a great example of "creeping featurism". At best it introduces unnecessary complexity, and at worst those reliant on it will be encouraged to pay less attention to what they're doing.

What I don't get is why anyone would want to allow the automation. Is it really that difficult to use the up-arrow key and correct the mistake? Doing something automatically when it's sort-of correct is a recipe for doing things you didn't intend to do.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#226
post #179

Earlier quoted context omitted.

isatty() is spoofed in e.g. Make via PTYs. It's a light check at best and lies to you at worst.

If make is going to spoof the PTY, it should take responsibility for answering the autocorrect prompt

There's no "prompt". That's not how TTYs work. Make has no idea the program is waiting for any input.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#227

IMHO this is a great example of "creeping featurism". At best it introduces unnecessary complexity, and at worst those reliant on it will be encouraged to pay less attention to what they're doing.

What I don't get is why anyone would want to allow the automation. Is it really that difficult to use the up-arrow key and correct the mistake? Doing something automatically when it's sort-of correct is a recipe for doing things you didn't intend to do.

Double this. If I don't type the command that I want, I never want my computer guessing and acting on that guess. Favors like that are why I hate Microsoft Word ("Surely you didn't mean XXXX; I'll help you by changing it to YYYY. Oh, you did it again, and in the same place? Well, I'll fix it again for you. High five!")

Re: Why is Git Autocorrect too fast for Formula One drivers?

#228

Earlier quoted context omitted.

That’s not automatically bad. There are two kinds of Hungarian notation: systems Hungarian, which duplicates information that the type system should be tracking; and apps Hungarian, which encodes information you’d express in types if your language’s type system were expressive enough. [1] goes into the difference. [1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

And this is exactly the kind the language should have a type for, Duration.

Not really.

I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth.

Just like I don't want to have a type for a float that means width, and another type for a float that means height.

Putting the unit (as oppose to the data type) in the variable name is helpful, and is not the same as types.

For really complicated stuff like dates, sure make a type or a class. But for basic dimensional values, that's going way overboard.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#229

Earlier quoted context omitted.

> But Ctrl+C are two key presses: reacting to type them both in under 100 ms is equivalent to a writting speed above 200WPM. I think people don't really type/press buttons at a constant speed. Instead we do combos. You do a quick one-two punch because that's what you're used to ("you've practiced"). You do it much faster than that 100ms, but after that you get a bit of a delay before you start the next combo.

As menctioned, pro-gamers train combos for hours daily. The best of them can press up to 10 keys per second without thinking. For example, the fastest StarCraft II player Reynor (Riccardo Romitti) can sustain 500 key presses per minute, and do short busts of 800. He has videos explaining how to tweak the Windows registry to achieve such rate (it involves pressing some keys once and the OS autorepeats faster than you…

You don't make a typo, press enter and then start reacting to the typo.

You start reacting to the typo as you're typing. You just won't get to the end of your reaction before you've pressed enter.

The point of my combo comment is that pressing Ctrl + C is not the same thing as typing two random letters of a random word.

Combine these two things and I think it's possible for somebody to interrupt a command going out. The question is whether you can press Ctrl+C while typing faster than 100ms, not whether you can react to it within 100ms.

Also, people regularly type faster than the speed that pro StarCraft players play at. The sc2 players need the regedit because they will need to press Z 50 times in a row to make 100 zerglings as fast as possible, but you don't need that to type.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#230

The root cause here is poorly named settings. If the original setting had been named something bool-y like `help.autocorrect_enabled`, then the request to accept an int (deciseconds) would've made no sense. Another setting `help.autocorrect_accept_after_dsec` would've been required. And `dsec` is so oddball that anyone who uses it would've had to look up. I insist on this all the time in code reviews. Variables must…

Though, ironically, msec is still ambiguous because that could be milli or micro. It's often milli so I wouldn't fault it, but we use micros just enough at my workplace where the distinction matters. I would usually do timeout_micros or timeout_millis.

ms for microseconds would be a paddlin'. The micro prefix is μ, but a "u" is sufficient for easy of typing on an ascii alphabet.
Post reply on HN