Re: Emacs completion matches selection UI

[Toby Cubitt <tsc25@cantab.net>]

On Fri, Jan 03, 2014 at 10:39:00PM -0500, Stefan Monnier wrote:
> >> I suspect that :exit-function is "enough", tho it might require some
> >> ugly unreliable hacks to get at the needed data.  Please try it out and
> >> M-x report-emacs-bug requesting the extra features/data to be able to
> >> "do it right".
> > I still don't see how, if by "enough" you mean enough to emulate the
> > current Predictive functionality without effectively bypassing the
> > `completion-at-point' mechanism and running Predictive/Completion-UI code
> > instead.
> 
> I don't know enough about Predictive to be able to answer.

Predictive needs to know what was the final text that got inserted in the
buffer after the whole completion process finished. Expanding a string to
the longest common prefix doesn't count as finished as far as Predictive
is concerned.

> :exit-function is called when the completion ends and gives access to
> the choice made by the user, so it is sufficient to provide some kind
> of feedback about which was the right choice.

If :exit-function is called with STATUS = `finished` if and only if the
STRING that was inserted in the buffer was one of the candidates returned
by the `completion-at-point-functions' hook, I think that would be
sufficient for Predictive.

I couldn't easily understand from the docstring or from skimming the code
whether that's what it does. I'll try playing around with it more fully
to see what happens as soon as I have a spare moment. But for that I need
to hack together a completion function and :exit-function to test with.

> But there might indeed be issues about exactly when the :exit-function
> is called, for example, or how/when the choices are presented.

Certainly a richer completion UI would probably require some changes and
additions to `completion-extra-properties'.


> > `completion-at-point' is designed around "tab-completion", and
> > that just isn't a good match for predictive completion (or a popup.el
> > style UI, for that matter).
> 
> completion-at-point-functions is largely designed for the purpose of
> completion-at-point, but it is not restricted to that; so do not confuse
> the two.

I don't think I was confused about the relation between
completion-at-point and completion-at-point-functions. I was confused
about what exactly completion-at-point does, but I think I understand
now. I was wrong about it not being a good match for the popup.el UI,
which could quite easily replace the *Completions* buffer.

Just to be clear, by "tab-completion" I meant the style of completion
that expands a string to the longest common prefix if possible and stops,
or displays a list of possible completions if there's no common
prefix. Which is exactly what `completion-at-point' does.

This style isn't a good fit to predictive completion, since arguably the
whole point of predictive completion is to guess the most likely
completions from all the possible candidates, and make it as easy as
possible to quickly select one of those. Expanding to a longest common
prefix and then stopping has no place in this.

Anyway, this is a digression. It would already be possible to define
Predictive as a `completion-at-point' function. The current
`completion-at-point' *user-interface* isn't a particularly good fit to
Predictive, so the result would be crippled compared to
predictive-mode. But this thread is all about improving that UI. I see no
reason why, with a richer Emacs completion UI, Predictive couldn't work
just fine with `completion-at-point'.

Best,
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