You have to get used to adding a slight (about 3 keystroke, in my case) pause for it to expand an abbrev, or it eats the keystrokes typed then. I once sent mail to my friend "Jan" addressed to "January" :-). The only drawbacks are that you have to be careful that you don't define an abbrev that's also something you might want to type, because you might miss it. The first saves me a keystroke for the second "l", a shift for the "I" and a pinky move for the dreaded "'". You can save a lot of time on contractions, too, if you define the right abbrevs: I have "il", "dont", and "theyre" defined to "I'll", "don't", and "they're", respectively. The more you have, the faster you can type. I have just under 500 abbrevs-anything I type repeatedly. It's also handy for common typos, like "adn" which I have set to autocorrect to "and". For example, typing "although" instead of "altho" would be a major pain. You very quickly become dependent on the abbrevs. T4M fills the gap (mostly), especially since version 2 came out, which lets you turn it off in some apps (like terminal). I rely heavily on abbreviations in emacs, and the lack of a similar feature systemwide was a serious bummer. TypeIt4Me (lets you define short abbreviationsįor things you type all the time. Note: 'Enable access for assistive devices' needs to be turned on in the Universal Access System Preferences panel in order for this to work.
Here's my Address entry script: - Tom Robinsonproperty GlossaryEntry : "Tom Robinson" & return & ¬ "xx Garfield Street" & return & ¬ "Brooklyn" & return & ¬ "Wellington" & return & ¬ "Aotearoa New Zealand" & returnKeyIt(GlossaryEntry)on KeyIt(WhatToKey) tell application "System Events" set CharBuffer to "" repeat with i from 1 to number of characters in WhatToKey set ThisCharacter to character i of WhatToKey if ThisCharacter is "'" then keystroke CharBuffer set CharBuffer to "" keystroke "}" using option down else if ThisCharacter is "—" then keystroke CharBuffer set CharBuffer to "" keystroke "_" using option down else if ThisCharacter is "…" then keystroke CharBuffer set CharBuffer to "" keystroke " " using option down else if ThisCharacter is "–" then keystroke CharBuffer set CharBuffer to "" keystroke "-" using option down else set CharBuffer to CharBuffer & ThisCharacter end if end repeat if CharBuffer > "" then keystroke CharBuffer end tellend KeyItSpecial characters like ellipses and em-dashes were causing problems for keystroke, that's why they're special-cased above.
To insert into an e-mail, just position the cursor at the appropriate point in the body of the message, and run the script from Mail's scripts menu. In my ~/Library -> Scripts -> Mail Scripts folder, I've created a Glossary folder, and in there, I have a number of these scripts (identical except for the GlossaryEntry property). You may find it useful too, or as the basis for a fully-fledged script. I've written a 'quick & dirty' AppleScript to do this for me. I think you're gonna have to bring this one up with Rainmaker.I have a number of pre-defined text strings I like to insert into e-mail messages-address, bank account, etc. In that list of "all programs" you've tested, are there others with GUI front ends that have a UID other then the current logged in user? So it's unlikely that Retrospect itself is changing it, more likely something is triggered when the OS switches processes. Retrospect itself run as root, while this plist file is owned by the current logged in user. (the xxx characters are a unique number that's shared among other plist files in that folder on my drive, but I don't know what they mean and don't care to share them with the internets) It appears that changes to the Input Menu settings result in changes to It's obvious that Apple changed something major, so it's not too surprising that if Spell Catcher X (who's website is still talking about Tiger support) is using this as some sort of back-door method for text input that there might be conflicts. One of the things that Leopard is showing to be causing problems is with International Preferences.
0 kommentar(er)
