From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: Re: Is intellisense features integration in Emacs technically possible? Date: Thu, 23 Jan 2014 23:43:21 +0100 Message-ID: <20140123234321.26085e40@forcix.kollektiv-hamburg.de> References: <1390269670.2888.14.camel@localhost.localdomain> <83zjmpf80o.fsf@gnu.org> <877g9shqms.fsf@newcastle.ac.uk> <20140122194930.49ba60be@forcix.kollektiv-hamburg.de> <87fvoedebx.fsf@newcastle.ac.uk> <20140123215656.30bf63b8@forcix.kollektiv-hamburg.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390517043 15447 80.91.229.3 (23 Jan 2014 22:44:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jan 2014 22:44:03 +0000 (UTC) Cc: phillip.lord@newcastle.ac.uk, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 23 23:44:10 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W6T0L-0001vz-DS for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 23:44:09 +0100 Original-Received: from localhost ([::1]:43547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6T0L-0003ZQ-2a for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 17:44:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6T0C-0003Y3-Lv for emacs-devel@gnu.org; Thu, 23 Jan 2014 17:44:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6T06-0001ao-Pp for emacs-devel@gnu.org; Thu, 23 Jan 2014 17:44:00 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:46868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6T06-0001aZ-KL for emacs-devel@gnu.org; Thu, 23 Jan 2014 17:43:54 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id 7324920136B; Thu, 23 Jan 2014 23:43:23 +0100 (CET) Original-Received: from forcix.kollektiv-hamburg.de (x2f0f3d1.dyn.telefonica.de [2.240.243.209]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id BAE58201367; Thu, 23 Jan 2014 23:43:22 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.230.15.51 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168986 Archived-At: On Thu, 23 Jan 2014 17:13:47 -0500 Stefan Monnier wrote: > > Important features I haven't seen for c-a-p-f yet: Provide an > > overlay of the most likely completion candidate while you type for > > quick completion with TAB; add annotations to completion > > candidates, for example to indicate symbol type; ability to provide > > documentation for a completion candidate so that can be shown while > > browsing candidates. > > c-a-p-f AFAIK refers to "completion-at-point-functions", which is > where the *backends* live. AFAIK none of what you cite would be > affected by or need changes in completion-at-point-functions. > Instead those issues affect the completion UI used on top of > completion-at-point-functions, which could be completion-at-point, > company, icomplete, or anything else. I think there is currently no provision for the backend to return annotation information or documentation that complements the actual completions? That I meant is that the completion table returned by a member in `completion-at-point-functions' would need some way of returning not only the possible completions at point, but also additional information in some standard way so that the frontends can display them in addition to the completions. > But returning completion candidates asynchronously is not compatible > with the current all-completions/try-completion API, so we'd need > a fairly serious rework of minibuffer.el. Do you think reworking minibuffer.el to support both types of calls with a unified interface (for example with the possibility to block until the asynchronous call returns if we need the completions "right now") would be the right thing? Alternatively, a separate in-buffer completion behavior akin to or based on auto-complete.el might make more sense? Jorgen