From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Is intellisense features integration in Emacs technically possible? Date: Thu, 23 Jan 2014 20:40:36 -0500 Message-ID: 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> <20140123234321.26085e40@forcix.kollektiv-hamburg.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390527775 30927 80.91.229.3 (24 Jan 2014 01:42:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2014 01:42:55 +0000 (UTC) Cc: phillip.lord@newcastle.ac.uk, emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 24 02:43:01 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 1W6VnR-00011m-NF for ged-emacs-devel@m.gmane.org; Fri, 24 Jan 2014 02:43:01 +0100 Original-Received: from localhost ([::1]:44022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6VnR-0004fT-4S for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 20:43:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6VlF-0001bv-5D for emacs-devel@gnu.org; Thu, 23 Jan 2014 20:40:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6Vl7-0000sm-Rw for emacs-devel@gnu.org; Thu, 23 Jan 2014 20:40:45 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Vl7-0000sP-I8 for emacs-devel@gnu.org; Thu, 23 Jan 2014 20:40:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+Jkg/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFHO+Jkg/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45955666" Original-Received: from 206-248-153-32.dsl.teksavvy.com (HELO pastel.home) ([206.248.153.32]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Jan 2014 20:40:36 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 21F956019C; Thu, 23 Jan 2014 20:40:36 -0500 (EST) In-Reply-To: <20140123234321.26085e40@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Thu, 23 Jan 2014 23:43:21 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:168989 Archived-At: > I think there is currently no provision for the backend to return > annotation information or documentation that complements the actual > completions? Yes and no. The completion-at-point-functions can return any number of extra properties, and Company uses that to let the backend provide various extra info (see lisp-completion-at-point in a recent lisp.el for an example). IOW you can provide as much extra info as is currently supported by Company. >> 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? Could be. I haven't thought enough about it to know. The problematic part that immediately springs to mind is things like partial-completion which make various calls to the backend to construct the "list of candidates". This would need to be rewritten in a "continuation passing style" (or event-driven style, if you prefer), I guess, but that'd be rather inconvenient. > Alternatively, a separate in-buffer completion behavior akin to or > based on auto-complete.el might make more sense? Not sure what that would look like. `completion-at-point-functions' has 2 "call levels": - first level is: we call the functions on that hook to know if there's a completion and (if there is) what kind of completion it is (boundaries, completion-table, properties, ...). - second level is: we call the completion-table to get the list of candidates. Doing the second level asynchronously means to rewrite partial-completion and friends in CPS. But maybe we can get by with only doing the first asynchronously. IOW the first level could return an :async property which is a function which you call with a continuation. That function will contact some external process and when it's ready it will call the continuation, passing it the real completion-table. And of course, we'd need to make sure that non-async uses can also just wait for the process to return the completion data. Stefan