QuickCursor would be all the more useful if it could support more applications. The existing accessibility-based mechanism is effective for many applications, but, as noted, not some critical ones like Mail.app. Alternate methods (like simply automating copy-paste via Apple Events) would be a great fallback for some applications. An internal greylist of essential apps for which fallbacks are required would streamline this process without user intervention.
I agree this would be a good idea. At the moment I don't have time to do it, but I'll keep it in the back of my mind.
Indeed, I may one day find time to add this, myself—I mostly filed the request here to be official, and in case someone else got to it first.
Just looked into this a bit... and I think an easier approach will be to just use the accessibility api to call the "Select All", "Copy"... and then on the return "Paste" menu items. The one issue with this approach is that it will overwrite the users pastboard, but I don't really see any other approach, and I think any applescript approach would have the same issues.
Running into a bit of a problem. To get the data back in (paste) doesn't really work. The problem is that paste only works in an app if the app is foreground. And since the text is supposed to be written back in on every save in the external editor, that's not really possible.
as a fallback I think it's perfectly acceptable to switch back to the originating app, paste, and then switch back. Maybe add a "Disable fallback" pref item if it annoys people.
But it'd be much better to be able to do it a little bit than to sacrifice all if it for only 1 part of it.
Also, please don't have it do a select all unless there's no selection yet. It'd be ideal to only edit the selected text (if there is a selection)
+1 on this, in any implementation possible. Instead of dealing with copy/paste, what about using the command-line hooks that many editors provide? You could save to a temporary file, launch a script with mate* or subl or whatever, and when it saves it, you'd have the data in /tmp.
Come to think of it, I wonder if you could generalize https://github.com/robtillotson/EditorClient, which is an ODB shim that does exactly this..
* Obviously you don't need this for TextMate, since it supports ODB, but it's an example.