I’m not sure whether automatic text completion on a mobile device is a net good. It sometimes saves a few taps, but it seems like it’s at least as likely to cause extra work.
Although I’m ambivalent about autocomplete on my phone, I like it in my text editor. The difference is that in my editor autocomplete is
- configurable,
- transparent,
- intentional.
I value these characteristics, but I understand that not everyone does, especially on a mobile device.
Abbrevs
Emacs abbrevs (abbreviations) are completely configurable. The only abbrevs the editor knows about are the ones you ask for, and you can see (and edit) your set of abbrevs in an ordinary text file. You can easily toggle in and out of abbrev-mode, turning all abbrevs on or off.
You can also determine whether an abbrev applies to all modes or just some modes. For example, maybe you’d like imp to automatically expand to
import matplotlib.pyplot as plt
when writing a Python file, but not when composing an email in which you might wish to call someone an imp.
Abbrevs are not saved by default, but Emacs will ask you when you exit if you’d like to save abbrevs created during your session. This encourages experimentation. You can try out an abbrev before deciding whether to keep it, or define an abbrev for a single task with no intention of keeping it.
Emacs users often use some naming convention so that all their abbrevs begin with a key sequence they’re unlikely to type unless they want it to be expanded. I use “jc” as a prefix, both because these are my initials and because I’m unlikely to type these two letters for any other purpose. (Here’s a grid of other rare two-letter combinations.)
For example, I have an abbrev jciff that expands to the HTML sequence
↔︎
for the symbol ↔︎ to denote iff (if and only if). The first character is the symbol itself, and the second character is a variation selector asking browsers to render the symbol as text and not as an emoji.
Dynamic abbrevs
An advantage of autocomplete on a mobile device is that you don’t have to go to the effort of programming completions that you might want. Emacs has something similar in what it calls dynamic abbrevs. These are completions based on the text in the file you’re editing.
For example, suppose you’re writing about politician Hery Rajaonarimampianina. After having typed his name once, the second time you could type a few letters of his name and then type Alt-/ to have Emacs fill in the rest. If you haven’t typed enough letters to uniquely determine his name, you can type Alt-/ repeatedly to cycle through the possibilities. Note that you have to initiate the text completion. Emacs will not insert a single character unless explicitly asked to do so.
What to abbreviate
Of course abbreviations are a matter of personal choice. Some people use text expander programs with hundreds of abbreviations. I reserve editor abbreviations for long blocks of text, such as boilerplate HTML, or text like the example above that is difficult to remember or error-prone to type. I don’t find it worthwhile to have lots of minor shortcuts because I won’t remember that I’ve created them. (See the previous post for a discussion of remembering what you’ve automated.)
If you abbreviate something because you find it hard to remember, you trade the task of remembering the thing itself with the task of remembering the abbreviation. I would be cautious about accepting this trade-off. It’s often better to simply memorize the thing that’s hard to remember, because then you can use it in more contexts.
In the example above I abbreviate two Unicode character code points. I abbreviate these rather than memorizing them because I don’t need to use them very often, but often enough that I’ve had to look them up a few times. I’ve memorized several Unicode code points because I need them often enough to justify memorizing them.
It’s a minus for me since its guesses are most often wrong for me, I don’t know of a way to turn it off on iOS.
Normally I like swipe on mobile screen keyboard (swipe finger over letters of word and it predicts the word) but it’s very frustrating when it gets it wrong (partly because it gets it wrong several times in a row when you retry!). It seems to prefer uncommon words over more common words, and it doesn’t learn from my typing. IMO it needs to use a combination of 1) predicting more common words over less common words, and 2) predicting the words you use more frequently.
One of the most common words I type is my wife’s name. It’s a very common English name but it’s one of the words which autocorrect will try everything it can to avoid me typing that name to the point where it’s easier to type it out letter by letter.
And when I type uncommon words letter by letter, it autocorrects to something else. I was typing letter by letter because I know you probably don’t know this word – don’t autocorrect me in this instance!
These suggestions don’t seem like particularly complex things to implement, I don’t think they’re hard problems!
Sort of along those lines, it frustrates me when adding terms to a query produces more results. It’s logically backward. I wrote about this here.