Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Thu, 02 Jan 2014 13:10:11 -0500 Stefan Monnier <address@hidden> wrote: 

SM> I'd love to see company-mode and completion-ui consolidated into Emacs's
SM> core code.  The "completion sources" would be provided via
SM> completion-at-point-functions, so we already have a place for
SM> that part.  We don't yet have an API for the "completion UI
SM> frontend", OTOH, so if we can agree on a good API for that part, we
SM> could restructure the minibuffer.el code around that and then add
SM> more UIs.

Based on the discussion so far, it seems that:

- there are good use cases for both completion-ui and company-mode, we
  can't claim either is a superset of the other.  The two are not
  fundamentally incompatible.

- I personally used company-mode heavily in the last few weeks and it
  works great, but I don't like that after a timeout, the up/down keys
  get taken over.  I think displaying the completion candidates could
  happen after a timeout, but selecting from them should happen only
  when the user explicitly requests it with M-TAB in a buffer or TAB in
  the minibuffer.

- it should be possible to implement a generic frontend for completion
  that both can use, and other tools like yasnippet can use IIUC.  The
  eventual goal is to have "something" standard in Emacs that all such
  packages (except perhaps helm, which is completely apart in its UI)
  would use.  We have to ask Dmitry and Toby, among others, to guide us
  with their experience of writing it once already, and we have to make
  sure we don't end up with a solution no one wants to use :)

- the backend data should be able to carry more than plain strings,
  things like docstrings and such, and IMO we should try to standardize
  the possible extras at least somewhat.  We may need a deeper backend
  abstraction than `completion-at-point-functions' because of this.

- the frontend choices made by the user should be able to feed back into
  the data backend (the "predictive" use case)

- we have enough interest and support in this work that it's worth
  undertaking in earnest after the code freeze.  The discussion should
  remain on emacs-devel (based on the wide interest so far).

I hope everyone agrees.
Ted