![[Home]](https://www.emacswiki.org/images/logo218x38.png)
Given the beginning of a word, Predictive Mode is a minor mode that tries to predict the rest of the word, and offers you an appropriate completion.
It’s at version 0.23.13 (released April 2012), but it’s still undergoing steady development at the moment, so don’t forget to check for updates every so often.
Note that the git repository URL is a git repository, not a web-site. You cannot view it in a web browser. To grab the latest development version, clone the repository using:
git clone http://www.dr-qubit.org/git/predictive.git The predictive completion package uses the CompletionUI, AutoOverlays, DictionaryTrees, Tries, TaggedNFA, Heaps, AVLtrees, and Queues packages. For convenience, these are included in the download file (linked above).
Please send bug reports and suggestions to toby-predictive@dr-qubit.org (you can post them here as well if you like, of course). I don’t check this page regularly, so anything not emailed to me is likely to languish here unnoticed for some time.
Scavenged from the manual:
The languages we use to communicate contain a large amount of redundancy. Given the first few letters of a word, for instance, it’s not too difficult to predict what should come next. Try it! You can probably easily guess how to fill in the missing letters in the following sentence:
Giv th fir fe lett o a wor i no diffi t predi wh shou com nex.
This is even more true of languages used to communicate with computers, which typically have very restricted vocabularies and rigidly defined grammars. Predictive completion exploits this redundancy by attempting to complete what you are trying to type before you’ve finished typing it.
What benefits does predictive completion bring?
The predictive completion package is fairly complicated, so it’s worth reading the manual to learn how to use it to the full. But if you just want to try it out quickly, then download the predictive package from the link above, unpack the files from the tar archive which will extract them to a new predictive/ subdirectory, byte-compile all the Lisp files by running make in that directory (otherwise performance will suffer hugely), move the Lisp files to a directory in your load-path, and add the following line to your emacs configuration file:
(require 'predictive)
The default behaviour is quite instrusive, but predictive mode can easily be customized to make it less so. The manual is your friend! (For the impatient: try browsing the Predictive and, especially, the Completion-UI customization groups.)
See the AUCTeX page for more screenshots of Predictive Mode in action.
One of the easiest ways of using Predictive Mode is to start with an empty dictionary and let it learn automatically. In this case, it learned the stuff in the paragraph the user just typed. The last word starts with a T and thus Predictive Mode predicts you want either “The” or “Temple”.
If you wait for a few moments, or use the appropriate key, you get a menu, too:
If you type a second letter, Predictive Mode will automatically narrow down the completions it offers. Type a space or punctuation to accept it.
Here’s the Predictive Mode setup used for the example above:
(add-to-list 'load-path "~/elisp/predictive") (autoload 'predictive-mode "predictive" "predictive" t) (set-default 'predictive-auto-add-to-dict t) (setq predictive-main-dict 'rpg-dictionary predictive-auto-learn t predictive-add-to-dict-ask nil predictive-use-auto-learn-cache nil predictive-which-dict t)
And here’s the explanation:
‘M-x predictive-create-dict rpg-dictionary RET ~/elisp/rpg-dictionary RET’ (where ~/elisp is on my ‘load-path’, obviously).MathiasDahl has posted a nice tutorial about using predictive mode on his blog: http://klibb.com/cgi-bin/wiki.pl/Emacs_Blog_2007-01-20
Phillip Lord’s PredictiveAbbreviation package provides features that are on the face of it quite similar to PredictiveMode. In fact, there are fundamental and important differences, and the two packages will appeal to different users depending on what exactly they want. It should be emphasised that predictive mode is much more complicated, probably less well tested, and very likely contains more bugs than pabbrev mode. If you want something simple and lightweight, I strongly recommend pabbrev mode. On the other hand, if you’re prepared to put in the time and effort to understand and configure predictive mode, it is much more flexible and powerful than pabbrev mode. For example, predictive mode can even be configured to simulate pabbrev mode!
The main difference is that predictive mode normally uses predefined dictionaries to lookup possible completion candidates, whereas pabbrev works rather like DynamicAbbreviations: possible completion candidates are scavenged from the text in the buffer. Each approach has its advantages and disadvantages. Creating and training the predictive mode dictionaries requires some effort, and they will probably adapt more slowly to the idiosyncrasies of the particular piece of text that you’re writing. On the other hand, pabbrev mode will only ever offer completions that you have already used in the buffer, so it won’t help in typing or spelling words you haven’t used yet. (This is nearly, but not quite true – pabbrev dictionaries are one per major mode – so the completion can be across any buffer that is, or has been, open. For text, this difference isn’t that important. But when using with Java, for instance, it makes a huge difference as you can complete identifiers defined in another source file — PWL pabbrev.el author). And if you accidentally mis-spell a word once, it will offer the mis-spelled word as a completion in future, which tends to propagate mistakes throughout your text.
However, predictive mode includes a number of features which can mitigate many of these disadvantages. Enabling buffer-local dictionaries (predictive-use-buffer-local-dict) and increasing the buffer-local learning rate (predictive-buffer-local-learn-multiplier) can make predictive mode adapt much faster to the text in individual buffers. Buffer-local dictionaries are not predefined: they are built up from words used in a buffer. But unlike pabbrev mode, only correct words (that also exist in the main dictionary) are added by default. Enabling the auto-add feature (predictive-auto-add-to-dict), which automatically adds all the words you type to the dictionaries, will build up a dictionary rapidly. The price is the same disadvantage as pabbrev mode: any mis-spelled words will also be added. Training the dictionaries on existing samples of your own writing will speed up the rate at which the dictionaries adapt to your individual writing style (predictive-learn-from-file or predictive-learn-from-buffer commands). Using different dictionaries for different kinds of writing (e.g. academic articles, emails, code documentation, etc.) will allow each dictionary to adapt to the different styles of writing involved.
The following predictive mode features have no equivalent in pabbrev mode:
\begin{...} or \end{...}, etc. Pabbrev mode has no similar way of completing on different sets of words within different regions of a buffer.the is always given precedence over there and their, however often you use the latter two. This is particularly relevant when using auto-completion.There are many completion packages available for Emacs. How does predictive completion compare? Warning: the following may well be somewhat subjective, since I’m obviously more familiar with predictive mode than the others…
There are two aspects to completion: which completions are offered, and how to choose one of them.
(which completions are offered)
the will always be offered before there, even if you use there far more often.(how to choose a completion)
PredictiveMode doesn’t really make typing much quicker, especially typing prose. It’s very hard to maintain the flow of the sentence when your editor keeps interrupting you with the wrong words. It’s even harder if you attempt to use any of the completion UIs to select anything other than the first choice; the process of cycling through a list of other words is very disruptive.
Have you actually tried PredictiveMode? You say the “editor keeps interrupting you with the wrong words”. But PredictiveMode doesn’t interrupt you at all unless you tell it to. The default configuration lets you type as normal, ignoring the completions entirely, unless you explicitly hit a key-sequence to insert a completion or bring up a completion UI.
As for the speed claims, unless you’ve carried out a proper study and can point to the data, this is a very subjective comment. I personally find it speeds up typing long words because I can type a few characters, sufficient to narrow down the options enough so that the word I want is the first choice, and then hit <space> to insert the word without typing the rest of it. (I have it configured so that punctuation characters accept the current completion.) Over time, my fingers have “learned” these shorter key sequences for commonly used words.
Whether this speeds up my typing overall is debatable. Like you, I don’t have any hard data.
In any case, this discussion is somewhat moot. I originally wrote PredictiveMode partly as a spelling aid, and partly to save key-strokes when I was suffering from mild RSI. (You may well question the wisdom of writing a largish piece of software as a way of combating RSI…!) I still find those the most useful aspects.
Based on Toby’s suggestion, here is what I have for saving keystrokes.
The purpose of the receipt is to let me to type as few as possible but without looking at the echo area nor tool tips nor any display of other options, in order to save keystrokes as much as possible, while not being distracted from the flow of writing.
Predictive is very powerful, it takes time to figure out. I hope that this receipt could help those who just want to save time in entering key-strokes.
For example, for the very common word: “the”, it would be help to complete with “he” when I type character ‘t’, but it does not help to suggest the remaining ‘e’, but distract when I already type “th”. So I wondering if the dynamic completion could be even more smart by checking on the remaining characters left to complete in the most likely completion, if it’s smaller than a set threshold stop the completion. Not sure if it’s already supported? I’ve read the manual, but could not find any clue.
— YuShen
This isn’t currently supported. It’s not at all clear how to me how you want it to work. The current most-likely completion of “th” might be “the” which you consider too short to be worth highlighting in the buffer. But that will change as soon as you type “r” instead of “e”, at which point the most likely completion switches to “through” (say), which you would consider worth inserting. Do you really want to oscillate between inserting and not inserting the most likely candidate in this way? Sounds confusing to me. Even if there’s a sensible way to make it work, I’m not convinced it will have much benefit. I’m assuming you’ve already turned off the all the more distracting interfaces (tooltips, echo-area, etc, most of which can be accessed by key bindings anyway), just leaving dynamic completion. Is the fact that the “e” of “the” is highlighted in the buffer really such a distraction? After all, you can always and type the “e” anyway and not bother to pause to see what the completion is.
– Toby