The following variables affect the overall behaviour of predictive mode:
accept and reject, which accept or reject the
completion, and accept-common, which accepts the longest common
substring of the completion but deletes the rest.
accept and reject, which accept
or reject old completions, leave, which just leaves any old
completions in place to return to later if you so desire, and
ask, which asks you whether you want to accept or reject each
completion.
completion-hot-to-resolve-old-completions controls what happens
when you move the point away from a provisional dynamic completion
(see Dynamic Completion) and start typing elsewhere in the
buffer. When auto-completion-mode is disabled,
completion-accept-or-reject-by-default determines how the
current completion behaves. If it is set to reject, the
completion user-interfaces serve only as a visual indicators; a
completion will not become part of the buffer unless you explicitly
accept it. If completion-accept-or-reject-by-default is set to
anything else, completions really are part of the buffer, and you must
explicitly reject them to get rid of any inserted characters.
When auto-completion-mode is enabled, completion-accept-or-reject-by-default has no effect. More fine-grained control is instead provided by auto-completion-syntax-alist and auto-completion-override-syntax-alist. See Auto-Completion Mode.
There is one exception to all this: whether or not auto-completion-mode is enabled, if you move the point to somewhere within a dynamic completion and start typing, the part of the completion before the point is always accepted (and the remaining characters deleted). This is almost always what you intended, and leads to less surprises.
Predictive mode doesn't play all that well with overwrite-mode. The completion-overwrite option implements an intelligent, partial over-write behaviour for completions. This only has an effect if you try to start completing with the point in the middle of a word. When completion-overwrite is enabled, the part of the word at point that comes after the point will be over-written by the completion. When disabled, the completion is simply inserted in the middle of the word, without deleting the rest of it.
Setting completion-max-candidates to a large number is probably not useful, and will slow predictive mode down. It is easier to type a few extra characters than cycle through lots of completions, and the number available directly via hotkeys is limited by the number of keys you are prepared to set aside for selecting completions (see Completion Hotkeys).
completion-highlight-face is used to highlight the current dynamic completion in the buffer, and also to highlight the currently selected completion in the tooltip and pop-up frame.
Setting predictive-auto-correction-no-completion changes
predictive mode from being a completion mode to being an auto-correction
mode. It relies on you defining equivalent characters in
predictive-equivalent-characters or useful prefix expansions in
predictive-prefix-expansions (see below). For example, if the
former defines all accented variants of characters to be equivalent,
then predictive mode will auto-correct accents for you, but without
offering completions of the words. If you enable
predictive-auto-correction-no-completion, you will almost
certainly want to enable auto-completion-mode
(see Auto-Completion Mode, change the default
auto-completion-syntax-alist ‘Acceptance behaviour’ to
‘punctuation accepts’ (see Syntax), and set
completion-accept-or-reject-by-default to accept (see
above).
The result of expanding a prefix according to predictive-equivalent-characters and predictive-prefix-expansions must produce a valid regexp, which is used to match prefixes that are considered equivalent to the one actually typed. Only a subset of the full Emacs regular expression syntax is supported. There is no support for regexp constructs that are only meaningful for strings (character ranges and character classes inside character alternatives, and syntax-related backslash constructs). Back-references and non-greedy postfix operators are not supported, so `?' after a postfix operator loses its special meaning. Also, matches are always anchored, so `$' and `^' lose their special meanings (use `.*' at the beginning and end of the regexp to get an unanchored match).
predictive-equivalent-characters works by substituting a character alternative listing all the equivalent characters whenever those characters appear in the prefix. It merely provides a more convenient way of defining these commonly used expansions, and is exactly the same as adding those expansions on to the very end of predictive-prefix-expansions. Any expansions defined in predictive-prefix-expansions therefore take precedence over character equivalences defined in predictive-equivalent-characters.
The main use of predictive-equivalent-characters is to make certain characters, e.g. the same character with and without diacritics, equivalent as far as completion is concerned. For example, if predictive-equivalent-characters was set to
("[eéêè]" "[EÉÊÈ]" "[aâà]" "[AÂÀ]")
then all accented and unaccented versions of ‘e’ will be treated as equivalent, and similarly for ‘a’. So typing ‘et’ would offer ‘être’ and ‘était’ as completions, as well as ‘et’. In this way, predictive mode can automatically correct accents and other diacritics as you type words. As with any auto-correction or spell-checker, be careful when using this: if there are two words that are identical up to diacritics, such as ‘a’ and ‘à’, then predictive mode can't telepathically know which one you want1, and will insert whichever is the most likely.
Pre-defined predictive-equivalent-characters and predictive-prefix-expansions settings for some languages can be selected when customizing these variables.
When predictive-ignore-initial-caps is set, only the first capital letter of a string is ignored. Thus typing A would find ‘and’ (which would complete to ‘And’), ‘Alaska’ and ‘ANSI’, but typing AN would only find ‘ANSI’, whilst typing a would only find ‘and’.
If an absolute path is used, all auxiliary files for all predictive-mode buffers will be saved to the same location. In this case, there are no safe-guards to prevent two different auxiliary files that happen to have the same name from clobbering one another. That said, only identically named files in different directories pose a risk.
Depending on the settings you have chosen, predictive mode may not create any auxiliary files at all. The only one created in standard predictive mode buffers is the buffer-local dictionary (see Automatic Learning). However, the predictive mode support for a number of major-modes makes extensive use of auxiliary files. See Major Modes.