Making sense out of Emacs completion mode choices

Question

There appears to be many alternative Emacs auto completion mechanisms. Without an exhaustive search, the following come to mind: ido, auto-complete, icicles, in buffer completion, minibuffer completion and standard out of the box completion. And then there is code completion. Lots of it. And much of it language dependent. It would be very useful to have an Emacs guru, or three, summarize the benefits of the major players in both code and non-code auto-completion. And this being Stack Overflow, it goes without saying that it would be good to identify the auto completion modes that work best for Emacs's IDE-like mechanisms.

Update: I just discovered the Emacs Wiki completion page which amplifies my basic question: of all these choices, what's good, what's less good and if you could only play with 2-3 which would you recommend?

Answer 1

I generally use two completion packages (other than the built-in TAB completion in the minibuffer and comint buffers).

pabbrev.el - which provides a suggestion at the cursor (press TAB) to accept. The choices are made by looking at word frequency. I like this because of the visual indication of what would be completed - but it mostly works for just one completion.

hippie-expand - which is generally bound to M-/ in place of dabbrev because it does all that dabbrev does and more. This works well when you might need to cycle through some alternatives, or if you want to complete a filename or something else.

I like both because they don't require any mouse movement and work quickly.

Answer 2

Wrt Icicles --

For the most part, Icicles is about minibuffer completion. There are a few cases where it offers something for in-buffer (e.g. code) completion, but it is mainly about minibuffer completion.

When most people think about minibuffer completion they think of file-name completion, buffer-name completion, and command-name completion. But there is a lot more to it.

As an Emacs-Lisp programmer, you can use completion wherever you want to give users a choice interactively. That's pretty general!

Completion is really about pattern-matching to define sets, which you can then manipulate.

Most people think that the only aim of minibuffer completion is to choose a single name (file, buffer, command, variable,...). But the power of completion is really to filter and possibly sort the complete set of file names, buffer names, etc. in different ways, and then to let users do something to or with the resulting set (not necessarily a single object).

That's what Icicles is about: letting you dynamically (incrementally) define sets using pattern-matching, and then act on selected members or all members of those sets.

This is not so much the aim of Ido or the other completion packages, with the possible exception of Helm (Anything).

Unlike Helm (Anything), which privileges object names over object types and actions as its starting point, in Icicles you typically invoke a command to do something to one or more objects of a given type (e.g. buffers), and then you narrow down the set of those objects, typically by name-matching. It is often the case in Icicles that you can act on those objects in multiple but related ways within the same command.

In Helm (Anything), in general your input is matched first by object name against the entire universe of objects of all types, and afterward you narrow down to pick some operation(s) to perform.

Finally, keep in mind that each of the various completion approaches offers both something (e.g. commands) for end users and something (e.g. completion features) for programmers.

If you are doing code completion then you generally just want to complete the name at point. The main thing interesting about code completion is determining what the appropriate candidates are. For that, the textual (e.g. code) context is typically all-important. To offer smart choices, the completion feature needs to analyze the context (code), including any encompassing context (e.g. project code).

Minibuffer completion on the other hand can be used for any kind of choice and action, including multiple choice with multiple actions. Here, all parts are interesting: what candidates to offer, what you can do with them, etc.

Dunno whether that helps, but that's my take anyway.

Answer 3

I use standard tab completion in the minibuffer for file names, M-x commands and other things.

I also frequently use the M-/ keystroke (dabbrev-expand) for dynamic completion of any word in any of your Emacs buffers. It is fantastic, especially for long variable names. Here is the documentation:

M-/ runs the command dabbrev-expand, which is an interactive
autoloaded Lisp function in `dabbrev.el'.

It is bound to M-/.

(dabbrev-expand ARG)

Expand previous word "dynamically".

Expands to the most recent, preceding word for which this is a prefix.
If no suitable preceding word is found, words following point are
considered.  If still no suitable word is found, then look in the
buffers accepted by the function pointed out by variable
`dabbrev-friend-buffer-function'.

A positive prefix argument, N, says to take the Nth backward *distinct*
possibility.  A negative argument says search forward.

If the cursor has not moved from the end of the previous expansion and
no argument is given, replace the previously-made expansion
with the next possible expansion not yet tried.

The variable `dabbrev-backward-only' may be used to limit the
direction of search to backward if set non-nil.

See also `dabbrev-abbrev-char-regexp' and C-M-/.

Answer 4

You can look to company-mode or autocomplete package, that could use different completion sources, including CEDET, and they also allow to define new completion sources... For some programming languages, you can use CEDET directly...