Re: Emacs completion matches selection UI

[Toby Cubitt <tsc25@cantab.net>]

On Fri, Jan 03, 2014 at 10:45:37PM -0500, Stefan Monnier wrote:
> > Emacs, and what the API should look like, re-purposing (parts of) the
> > Company and/or Completion-UI code bases (maybe others too?) will be a big
> > head start (assuming no copyright assignment roadblocks).
> 
> Company is in GNU ELPA, so its copyright status is already clear.
> I'd be happy to see completion-ui in GNU ELPA as well.
> 
> > Think minibuffer completion, versus filename completion, versus
> > predictive completion, versus elisp code completion etc, all of which
> > might want to use slightly different UI options.
> 
> Not sure why.  Maybe I just don't understand what you mean by "UI
> options".  Do you have concrete examples in mind?

Sure.

If you're doing predictive plain-text completion, you probably don't want
to display all possible completions all the time. You probably want to
limit the list to the 10 or so most likely completions. You might also
want to set a minimum prefix length below which Emacs refuses to search
for completions (finding all completions of the letter "t" in an English
dictionary can take a while...unless you're using Predictive of course,
in which case it takes fractions of a second ;-)

Whereas for filename completion, you most likely always want to list all
the possible completions, and you probably want to show completions even
for single-letter prefixes.


Another example: the "dynamic completion" UI in Completion-UI is
something like `hippie-expand', mimicking the kind of thing you see in
IDEs, or LibreOffice, or mobile phones: the best completion candidate is
displayed highlighted in the buffer, and typing a space or punctuation
character inserts that completion. This a very useful and widely-used UI
for predictive plain-text completion.

For code completion, this UI is infuriating. You'll almost certainly
either want to disable it completely, or at least configure it so that
the highlighted completion only gets inserted in the buffer when you
explicitly tell it to with a specific key binding.


Yet another: For plain-test predictive completion, single-character
"hotkey" bindings to quickly select one of the first n completions are
quite useful, e.g. you might use the characters 0-9. But these
single-character bindings mean you can't type any of those characters
whilst you're completing. For filename completion, you'll almost
certainly want to disable these bindings.


I could go on. But maybe that's enough to convince you that it's useful
to be able to configure the UI slightly differently for different kinds
of completion. Even if most of the time you'll want to configure the UI
globally.

In Completion-UI, I have a `defcustom-per-source' macro (a drop-in
replacement for `defcustom') that automatically turns a standard
defcustom definition into one that can optionally take different values
for particular completion sources. So making customization options
configurable per-source is zero effort.

Hope that helps,
Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: tsc25@cantab.net
web:   www.dr-qubit.org