191–200 of 248 posts
Earlier quoted context omitted.
Milliseconds are a commonly-used unit. It doesn't really matter if 1 ms is too fine a granularity -- you'll just have to write "autocorrect = 500" in your config file instead of "autocorrect = 5", but who cares?
If you're going to store that unit in one byte (possible even signed) suddenly deci-seconds start making a lot of sense
> introduced a small patch > introduced a patch > the Git maintainer, suggested > relatively simple and largely backwards compatible fix > version two of my patch is currently in flight to additionally And this is how interfaces become unusable, through thousand small "patches" created without any planning and oversight.
Ah, if only the Git project had someone of your talents in charge (rather than the current band of wastrel miscreants). Then it might enjoy some modicum of success, instead of languishing in its well-deserved obscurity!
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.
Earlier quoted context omitted.
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.
NO is the country code for Norway.
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.
In fact, our French keyboards do have a "µ" key (as far as I remember, it was done so as to be able to easily write all SI prefixes) but using non-ASCII symbols is always a bit risky.
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…
for single mouse click, 225ms is pretty typical for me after a bit of warmup. sub 200 is not consistently reproducible. i dont think i've ever cracked < ~185ms
Earlier quoted context omitted.
Ah, if only the Git project had someone of your talents in charge (rather than the current band of wastrel miscreants). Then it might enjoy some modicum of success, instead of languishing in its well-deserved obscurity!
Git has notoriously bad CLI (as other commenters here noted). Your snarky comment provides no value to this discussion.
Earlier quoted context omitted.
Ed also uses "?" for "Are you sure?" If you're sure, you can type the last command a second time to confirm. The story goes that ed was designed for running over a slow remote connection where output was printed on paper, and the keyboard required very firm presses to generate a signal. Whether this is true or folklore, it would explain a lot. GNU Ed actually has optional error messages for humans, because why not.
https://www.gnu.org/fun/jokes/ed-msg.en.html "Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity."
Earlier quoted context omitted.
That value has also been criticised as too high.
What is the argument for it being too high? The argument for it being what it is is the fact that our auditorial processing (when using a starter pistol) or visual processing (looking at start-lights) takes time, as well as transferring that message to the relevant muscles. 100 milliseconds is a pretty good average actually
I don't have extensive resources/references at hand, but I've read about this a few times over the years.
Earlier quoted context omitted.
> 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…
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.