Built-in completion-at-point UI in Emacs is very simple. It’s usable – especially if you don’t mind the popup window, necessity to press tab after each letter, lack of support for asynchronous back-ends.
Most of the people choose alternatives like auto-complete or
company-mode. However, some people fancy ido. They prefer the flexible matching ido provides, and already use ido for finding files
and switching buffers. Maybe even for
M-x-ing. If only could you
have ido complete your code, too.
Ido is modular enough to provide it’s prompt function
separately. It’s called
ido-completing-read. So the rest seems
trivial. Just hook into the
completion-all-completions output through
ido-completing-read and insert the chosen candidate, right?
Suprisingly, the latter is the trickiest part.
The trick with inserting a completion is that candidates sometimes come with the common part and sometimes not.
For instance, in elisp-mode, if you autocomplete
predictably, it will give you
region-extract-function. No problem here, just remove the common
part, i.e. the original input
region-e, and insert the candidate.
Now take shell-mode. Suppose, your input is
Sites/Do. Press tab
and it suggests the following candidates:
Downloads. See? No common part.
The good news is that candidates from
come propertized. The common part is
highlighted with a special face property. Just look up the property span and you’ll see
if you need to remove anything from the input.
Let’s see how
through the built-in completion-at-point. First, it hooks into the
completion-at-point-functions variable, fetches candidates from a Node.js server, then displays them calling
Subjectively, every other completions backend should do the same. Exploit the built-in Emacs completions system, while different completion
front-ends can just set their own
By the way, you can override
ido-at-point-read to whatever you
like. For example, if you like GUI menus,
this code will display
candidates in technicolor.