Note 1: typing too fast

Lately I've noticed that when I type too fast for my Mac to keep up, the character input is sometimes not only delayed but out of order. Just recently, "To " came out as "o T" and "I didn't " came out as "idn't I". (A "d" got dropped in the latter case, but I can't say for sure I didn't accidentally leave it out myself.)

Anybody else seeing this? I don't think I ever saw it until recently. These examples suggest that it's not a simple case of me transposing two letters by mistake. It looks like the first character in my burst of typing gets pushed to the end, but I'll have to collect more examples to be sure of any pattern. I think it usually happens in my web browser — I forget which one.

As I recall, NeXTstep always guaranteed not only the character order you typed, but that the keyboard events would go to the window that was key at the time you typed them, even if for some reason they were delayed so long that you had already switched windows. I don't know if this is guaranteed on the Mac; I've never assumed it was. But I'd expect the events to at least be in the right order.

Note 2: cloud-based text editors

I use various "cloud-based" text editors on my iPhone — most often Elements, sometimes Simplenote, and rarely others. These editors synchronize local text files with either Dropbox or a web service, depending on the app.

I've noticed that if I launch one of these apps and immediately start typing, one of two things often happens:

1. The app scrolls to the bottom of the text file and what I type is appended to the file instead of inserted where the cursor was when I started typing.
2. I type a phrase and when I look up from the keyboard I see the phrase has been inserted twice.

I assume both of these are because I start typing before the app has finished retrieving the latest version of my file from the web. In the first case, my guess is that the app blocks while it retrieves my file and displays it in the editor view (thus putting the insertion cursor at the end), and only then does it handle the backlog of keyboard events.

In the second case, my guess is that the app is trying to be helpful. It remembers where my insertion point was, buffers my keystrokes while it asynchronously retrieves the file, and when the file has been retrieved it plays back the buffered keystrokes at the remembered insertion point. I'm guessing there's a bug in the "playback" code, but again, this is just a guess.

The workaround is to wait before I start typing. I wait until the network-activity indicator at the top of the screen stops spinning, and then I type. I would prefer that the apps enforce this workaround by making me wait. They should not let me start typing until the file is retrieved. I appreciate that these apps want to create the illusion that I can treat my files as if they were purely local, but I think this illusion is unsustainable.

These concerns are one reason I wanted to stick with Notespark, which has a different syncing model and does three-way merge instead of wholesale updating with the newest version of a file. It's a good app. I forget why I don't use it any more.

Note 3: not looking

A bit of personal trivia: sometimes when my eyes get tired I close them for a few seconds but continue typing. I do it when typing both code and prose. I kind of like the mental state this puts me in and the way it forces me to use my mind's eye. As a variation, sometimes I keep my eyes open but look away from the screen. Try it some time, you might like it.