Evan, how do I specify what characters are considered delimiters? In Text-Expander, and others, I can choose the characters to delimit the typed in text.
For example, I want a question mark (?) to be a delimiter and trigger text substitution. Can I do that with Spell Catcher? If so, how and where do I find it?
You see, -ac Christ expands to Anti-Christ.
But...
-ac? Expands to nothing.
Unless I am missing something, your test expansion leaves much to be desired, compared to your competition.
Please tell me I am wrong.
John
0
De-Limiters
Started by lcpguy, Feb 09 2009 01:21 AM
3 replies to this topic
#2
-
- Members
-
- 90 posts
Member
- Location:Ontario, CA
Posted 17 February 2009 - 03:13 AM
Evan. why haven't I heard on this subject?
Please, is there a way to specify de-limiters like in other programs? Please advise.
Thanx,
John
Please, is there a way to specify de-limiters like in other programs? Please advise.
Thanx,
John
#3
-
- Admin
-
- 2,986 posts
Administrator
- Gender:Male
- Location:Toronto, Canada
- Interests:This Place!
Posted 17 February 2009 - 06:12 AM
lcpguy, on Feb 17 2009, 03:13 AM, said:
Evan. why haven't I heard on this subject?
Please, is there a way to specify de-limiters like in other programs? Please advise.
Thanx,
John
Please, is there a way to specify de-limiters like in other programs? Please advise.
Thanx,
John
Been kind of busy lately, migrating to a new version of the Proximity Linguistic System we got last week, testing with the latest Snow Leopard seed, and beginning the migration of Spell Catcher’s input method component to a (Leopard and later) input method application (components will not work in 64-bit apps).
I don't think the particular example you cite has as much to do with delimiters as it does with the way hyphens and end-of-sentence characters are parsed and/or specially handled by the linguistic software we use.
If you simply change the abbreviation to "ac", without the leading hyphen, all should work as expected.
Not that this sort of thing couldn't be something I could specifically look for in Spell Catcher itself. Code would have to be written - a preference change alone won't do it. As things stand now, not even changing the set of characters that are considered delimiters will do the trick in this specific case (yes, it can be done, there's just no UI for it).
If you want to change the default set of delimiter characters, Quit the Spell Catcher app, open its preferences file (home ~/Library/Preferences/com.rainmaker.SpellCatcher.plist) with an app that can edit binary plist files (Apple's PropertyListEditor, part of the Xcode tools, PlistEdit Pro, BBEdit...) and modify the value for the SCExtraWordSeparatorChars key. Make sure to append to the existing string (<>=), best not to remove those.
You need to remember that the other utilities don't require proper parsing of words from surrounding text for linguistic purposes (spell checking, thesaurus, etc.) in such a way that it will work regardless of language. I'm unsure of all the possible side-effects that may be encountered when other than the current set used by Spell Catcher are used.
Other shorthand-only utilities don't need to take linguistics into consideration. Nor do they have the ability to do proper enclitic processing and expansion for languages like French where words are commonly prefixed (l', j', d', t'...), and language rules dictate what can and can't follow a given prefix. None have the ability to instantly replace text in (supporting) applications without resorting to backspacing. Only input methods can make replacements as quickly as Spell Catcher. Most of the others use the clipboard and Paste command to insert text - an approach that's complicated, and relatively easy to trip up. Not all handle inclusion of tab and return characters in expansions in such a way that the application processes them as commands (tab between fields, default button equivalents).
Tell me specific problems you need solved - that's the right way to consider adding features, rather than blindly allowing arbitrary delimiters without considering the impact on other linguistic features.
#4
-
- Members
-
- 90 posts
Member
- Location:Ontario, CA
Posted 19 February 2009 - 01:46 AM
Evan Gross, on Feb 17 2009, 03:12 AM, said:
Been kind of busy lately, migrating to a new version of the Proximity Linguistic System we got last week, testing with the latest Snow Leopard seed, and beginning the migration of Spell Catcher’s input method component to a (Leopard and later) input method application (components will not work in 64-bit apps).
I don't think the particular example you cite has as much to do with delimiters as it does with the way hyphens and end-of-sentence characters are parsed and/or specially handled by the linguistic software we use.
If you simply change the abbreviation to "ac", without the leading hyphen, all should work as expected.
Not that this sort of thing couldn't be something I could specifically look for in Spell Catcher itself. Code would have to be written - a preference change alone won't do it. As things stand now, not even changing the set of characters that are considered delimiters will do the trick in this specific case (yes, it can be done, there's just no UI for it).
If you want to change the default set of delimiter characters, Quit the Spell Catcher app, open its preferences file (home ~/Library/Preferences/com.rainmaker.SpellCatcher.plist) with an app that can edit binary plist files (Apple's PropertyListEditor, part of the Xcode tools, PlistEdit Pro, BBEdit...) and modify the value for the SCExtraWordSeparatorChars key. Make sure to append to the existing string (<>=), best not to remove those.
You need to remember that the other utilities don't require proper parsing of words from surrounding text for linguistic purposes (spell checking, thesaurus, etc.) in such a way that it will work regardless of language. I'm unsure of all the possible side-effects that may be encountered when other than the current set used by Spell Catcher are used.
Other shorthand-only utilities don't need to take linguistics into consideration. Nor do they have the ability to do proper enclitic processing and expansion for languages like French where words are commonly prefixed (l', j', d', t'...), and language rules dictate what can and can't follow a given prefix. None have the ability to instantly replace text in (supporting) applications without resorting to backspacing. Only input methods can make replacements as quickly as Spell Catcher. Most of the others use the clipboard and Paste command to insert text - an approach that's complicated, and relatively easy to trip up. Not all handle inclusion of tab and return characters in expansions in such a way that the application processes them as commands (tab between fields, default button equivalents).
Tell me specific problems you need solved - that's the right way to consider adding features, rather than blindly allowing arbitrary delimiters without considering the impact on other linguistic features.
I don't think the particular example you cite has as much to do with delimiters as it does with the way hyphens and end-of-sentence characters are parsed and/or specially handled by the linguistic software we use.
If you simply change the abbreviation to "ac", without the leading hyphen, all should work as expected.
Not that this sort of thing couldn't be something I could specifically look for in Spell Catcher itself. Code would have to be written - a preference change alone won't do it. As things stand now, not even changing the set of characters that are considered delimiters will do the trick in this specific case (yes, it can be done, there's just no UI for it).
If you want to change the default set of delimiter characters, Quit the Spell Catcher app, open its preferences file (home ~/Library/Preferences/com.rainmaker.SpellCatcher.plist) with an app that can edit binary plist files (Apple's PropertyListEditor, part of the Xcode tools, PlistEdit Pro, BBEdit...) and modify the value for the SCExtraWordSeparatorChars key. Make sure to append to the existing string (<>=), best not to remove those.
You need to remember that the other utilities don't require proper parsing of words from surrounding text for linguistic purposes (spell checking, thesaurus, etc.) in such a way that it will work regardless of language. I'm unsure of all the possible side-effects that may be encountered when other than the current set used by Spell Catcher are used.
Other shorthand-only utilities don't need to take linguistics into consideration. Nor do they have the ability to do proper enclitic processing and expansion for languages like French where words are commonly prefixed (l', j', d', t'...), and language rules dictate what can and can't follow a given prefix. None have the ability to instantly replace text in (supporting) applications without resorting to backspacing. Only input methods can make replacements as quickly as Spell Catcher. Most of the others use the clipboard and Paste command to insert text - an approach that's complicated, and relatively easy to trip up. Not all handle inclusion of tab and return characters in expansions in such a way that the application processes them as commands (tab between fields, default button equivalents).
Tell me specific problems you need solved - that's the right way to consider adding features, rather than blindly allowing arbitrary delimiters without considering the impact on other linguistic features.
Nevermind Evan. I see what you are saying. When I get rid of leading "-" things expand properly.
