[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs completion matches selection UI
From: |
Ted Zlatanov |
Subject: |
Re: Emacs completion matches selection UI |
Date: |
Fri, 03 Jan 2014 12:49:35 -0500 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) |
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
Re: Emacs completion matches selection UI, Dmitry Gutov, 2014/01/02
Re: Emacs completion matches selection UI, Dmitry Gutov, 2014/01/02