Mostly because I didn't have time for one and also because I wanted not to require people to listen to some speech to understand how GitUp works (which you can't always do at work anyway).
Would you mind paying for a code signing and two wildcard certificates for me then, please? Yearly, of course.
I would cover the costs out of my profits, but the $0.00/yr I am pulling in from my open source projects doesn't quite cover it, let alone the $200/yr for the VPS and domain registration.
Biggest annoyance with this software - backspace is, apparently, something that I alone exercise. If you type an incorrect letter, it simply doesn't advance the cursor rather than advancing the cursor and marking the letter as incorrect. Since I am already a pretty good touch-typist, I routinely KNOW I have hit an incorrect key, hit backspace, and correct it and progress with the word.
However, very often I will do something like spelling "icnorrect" from feeling, then hitting backspace exactly eight times and re-type "ncorrect"... which is simply not supported by this software.
This reminds me of a problem I face. I write documents in LaTeX all the time, and my preferred text editor is vim. In vim, CTRL-W will remove the last word in insert mode. This has become second nature to me, since I frequently find it faster to retype a whole word than to perform the correct number of backspaces to correct a typo midway.
What this really means is that I close browser windows with great frequency whenever I'm typing something and make a typo, and hit CTRL-W.
I have the same issue with screen sessions. I use Ctrl-a to move to the beginning of the line (an Emacs shortcut, also implemented in lots of shells), but screen's default command prefix is Ctrl-a. Of course, that one's simple to change.
Ctrl-a Ctrl-k in Emacs moves to the beginning of the line and then erases the line. In screen, that key combination kills the current window! At some point, screen added a "Really kill this window [y/n]" which was a terrific enhancement...
Ha, I don't remember running into that exactly. I have found several lines in my local text editor where I type "a" at the beginning because I mistakenly think I'm in screen, so I type "Ctrl-a a" instead of just "Ctrl-a".
…and on a Mac, to delete to the start of the line, type CMD + backspace. I started using this shortcut, and the parent one, about two weeks ago. They are just now becoming muscle memory, and I find them very useful.
FYI, in OSX a lot of emacs/shell shortcuts work in textboxes/-fields too. e.g., ctrl-a, ctrl-e, and ctrl-k respectively for beginning of line, end of line and deleting to end of line.
You should use pentadactyl then ;) Close browser windows with :t, Ctrl-w does nothing, clicking in a textarea and doing Ctrl-i opens a gvim window where you can edit your text properly. And much more.
Why can't we rebind this key to another key? Why not make CTRL+Q or CTRL+B remove the last word.
Something which really grinds my gears is when software has non-rebindable hotkeys. Why are keybinds hardcoded? We can change our controls in games from WASD to ESDF. Why can't we change our copy key in Windows from CTRL+C to CTRL+L, without using 3rd party software?
Having written my own applications on occasion, I know this isn't that difficult. So why is it so uncommon?
At least in vim, you can remap just about anything that you want to.
The reason the feature doesn't get included as often is because of exactly this. Even someone who could make use of the feature, and is annoyed by the current keybindings, doesn't take advantage of re-binding. The reason it is available on video games, on the other hand, is because its necessary for controller support, which a large enough portion of the video game community uses for it to have high demand.
I've played more than one game (Freespace, Tribes, Warframe) that had more than 30 keybinds. Managing keymaps can be challenging, but it's not impossible.
And discussing this reminds me how much of a pain it is. What we need is a system where we set our own defaults in an XML file or some other common format (or use a software tool to do that). Then we can select this keymap when we install applications.
There's no reason to keep the host key as right control if it causes problems like that. You can set it to something different in VirtualBox's global preferences (Control-G) > Input > Virtual Machine.
Also, you may prefer to run your VMs headless with vboxheadless (man vboxheadless). May save you some time and frustration, and video memory. Then ssh into them by going into the guest settings and forwarding port 22 to a host port (I use 12322).
I even did this during a test running in a browser at school. Luckily it was possible to reopen it and nobody noticed. I've done this so many times that I have some setup always running vim in the background in a tmux session only a keypress away.
Super+Shift+v then type <leader>y and paste in the browser.
If you want to type quickly, especially for something real-time like dictation, it's better to keep going and fix typos later. You don't want to train people to stop typing every time they mess up, because they might miss something.
I agree for skilled typists, but if you were just trying to learn the keys at first I could see wrangling backspace being more distraction than learning.
I disagree. In real word processors the cursor would move forward and people should get used to that, instead of having to learn one thing here and something else in the rest of the world.
I dunno, do you remember first learning to touch type? For all we talk about typing in keystrokes at a time, that's an exercise in frustration if you don't confidently know where each key is. 99.9% of your typing will be "real world" practice, but there's also utility in isolated drills.
Anyway, as someone who's tried to learn to type on prototype hardware without a working backspace, I appreciate the feature :)
Was coming to say exactly the same thing. The old Mavis Beacon program had the same issue which was that it expected you to just type to the end, eventually getting the right letter if you missed one and then correct the typos later. Whereas I seem to type ho[^Hpe a lot for 'hope'
The other thing that I'd love to see (I may have missed it) is typing proficiency on programming punctuation.
I'm not sure why this software behaves that way -- but it used to be a (mis)feature of measuring typing speed on mechanical typewriters -- there were no do-overs. The only way to correct would be to either go back and strike-through -- or manually correct, whiting out the error, and typing the correct word. The first wasn't really usable for "typed" letters and such -- and either would take much more time than on a word processor. Because of this, when measuring wpm/typing speed, errors are severely punished -- even if many of those can be taken care of with auto-correct and/or much faster manual correction.
I'm not sure sticking to this measure for typing speed now that hardly anyone uses typewriters -- but errors do break flow, and for that reason it is good to train towards perfect typing -- even if that means typing a little "slower".
>>I routinely KNOW I have hit an incorrect key, hit backspace, and correct it and progress with the word
Because that's a bad habit when deliberately practicing. A good typing program should have a couple of modes. One that forces you to keep moving forward even if you make a mistake (and not let you backspace, this develops speed). Another one that will make you stop until you hit the correct key (for beginners or to break bad habits).
An annoyance, yes it is. But I think it's a good feature. Not making mistakes is the most important thing to improve your touch typing speed. If this annoying behavior makes you slow down and stop making mistakes, instead of using backspace without thinking about it, then it's well worth it. That backspace reflex comes very quickly anyway, it's not really something you need to train.
We aren't trying to measure each hardware set as apples-to-apples, but rather give the reader an idea of how performance characteristics for a chosen stack are affected by hosting environment. Specifically, we wanted the middle-of-the-road EC2 instances versus the extremely high-end Peak option to illustrate that difference.
I've noticed a weird trend where amazon created various slices of instance types a long time ago, and people have mentally gotten used to using larger ones far slower than moores law adds cores. So people will refer to something with 2 cores as "middle-of-the-road" and 32 as "extremely high-end" when in my brain thats "a cell phone" and "a 2 year old server".
Our suite takes a nuke-from-orbit approach when it comes to killing processes, as this has come up in every round. The idea is that now all tests are run with a specific user, and instead of relying on the test to shut down properly (which MANY could not reliably do), we simply nuke all processes owned by this runner.
It has the downside that if a process forks other processes and drops them into another different user (recently addressed for hhvm, for example), we cannot capture that. However, we have made great strides in trying to avoid that. Additionally, the logging for the application WOULD suggest if a port were bound prior to start-up, and that does not seem to be the case in this example.
Yeah, you should see a java.net.BindException in that case. Play sends it to STDERR rather than STDOUT, I thought maybe that output was being redirected but that doesn't appear to be the case.
The other primary cause of that "oops" message is when evolutions can't be applied but that also doesn't appear to be the case.
Agreed. Our logging has undergone some solid improvements in the last week or two, and so round 11 will, if not resolve this issue completely, make the logged output more useful for tracking down issues like this during the preview runs.
Rust and Elixir SHOULD be included in Round 11 - we have already accepted a pull request for the Phoenix framework (Elixir) and have had a pull request for Rust when it was in alpha. Hopefully, we will see another Rust pull request soon.
"Humans are fleeing California, looking for a better life!" - CBSNews