Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X

spelling and auto-correct idiosyncrasies


spelling and auto-correct idiosyncrasies

I've been plunking around with spelling today and believe I have observed
the following:

Auto-correct word pairs:
Documentation is incorrect regarding userdict controlling word pairs. Jason
Buss reported this here a while back, I think. You can still customize
auto-correct by modifying autocorrect.xlf (found in the Editor install
custom/lib directory) manually. I copied autocorrect.xlf to my custom/lib
directory and edited it and got the behavior I expected. However, I deleted
all the contents of my autocorrect.xlf except for my customizations hoping
my entries would be added to the autocorrect.xlf entries in the install tree
but, no, when I did that, it overrode the entire file ... only my
autocorrect pairs were found. Auto-correct does not support replacing "e.g."
with "eg" although it will support the reverse.

You can add "e.g." or "eg" but not both.
Removing one removes either.
You can add "eg:e.g." but it will not auto-correct (as stated above). Both
will still be flagged.
When you add "eg:e.g." it is reported by a subsequent -list as "eg;e.g.".
(Note that's a semicolon, not a colon.)
It is not possible to reject word using userdict. (I was hoping for "-eg"
for example.)
It is possible to specify required capitalization using userdict however you
can't SEE it in -list. (An entry of "Apple" will flag "apple" but be
reported as "apple" by -list.)
It is not possible to flag capitalization where it is wrong using userdict.

spell command, aptspell.acp, aptspell.rjt
It is possible to flag missing capitalization using "spell -accept".
It is not possible to flag capitalization where it is wrong using "spell
Entries in aptspell.rjt files override aptspell.acp (this can only tested by
editing the files manually).
Entries in files override userdict.
You can accept e.g. but not eg OR eg but not e.g. HOWEVER, if you reject
either, both are.
When you "spell -delete" e.g. or eg, both are deleted according to the Edit
Window, but an entry may get left behind in an file and be
respected in the next edit session.

I still need to experiment with the environment variables regarding the
location of Specifically, what happens if I specify a location
to which authors only have read access. But it's lunch time ...

Paul Nagai

After simply making the files read-only, I learned that:

spell -accept and -reject fail with an appropriate message about no write
spell -delete of a word not in one of the files fails with a message
indicating the word is not in either file.
spell -delete of a word that *is* in one of the files "succeeds" and
successfully modifies Editor behavior for the duration of that session
without actually removing the word from the files. On an Editor restart, the
"deleted" word is "back".

I assume this behavior reflects what I can expect when the files are on a
network drive to which the author only has read access. If I find
differently, I'll let you know.

Sometimes you might think it would be easier just to hire some proofreaders.
Top Tags