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 17:13:47 -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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390515265 26945 80.91.229.3 (23 Jan 2014 22:14:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jan 2014 22:14:25 +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 Thu Jan 23 23:14:33 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 1W6SXf-00075Q-Ty for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 23:14:32 +0100 Original-Received: from localhost ([::1]:43443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6SXf-00068S-A6 for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 17:14:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6SXW-000679-6M for emacs-devel@gnu.org; Thu, 23 Jan 2014 17:14:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6SXL-0001Nd-Vd for emacs-devel@gnu.org; Thu, 23 Jan 2014 17:14:22 -0500 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:47706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6SXL-0001NN-On for emacs-devel@gnu.org; Thu, 23 Jan 2014 17:14:11 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 79EC1846CD; Thu, 23 Jan 2014 17:14:10 -0500 (EST) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 3A6A61E5AE3; Thu, 23 Jan 2014 17:13:48 -0500 (EST) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 0DCA6B40D4; Thu, 23 Jan 2014 17:13:48 -0500 (EST) In-Reply-To: <20140123215656.30bf63b8@forcix.kollektiv-hamburg.de> (Jorgen Schaefer's message of "Thu, 23 Jan 2014 21:56:56 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:168984 Archived-At: > First, it could be improved with more output options. For example, > emacs-jedi.el provides popup-style display for signatures: > http://farm3.staticflickr.com/2845/8793986161_e1c58607f0_o.png > Allowing the user to customize eldoc to use one or the other, > and then having that user's preference take effect in all programming > modes, would be excellent. eldoc-mode is fairly old and hasn't seen much development, so it's fairly primitive. I'd like to enable it globally by default, and I'd welcome some improvements in the UI as well. I personally really like the fact that it uses the echo area, but I agree that it would be good to provide the user with some alternative UIs. > Second, and this is a recurring thing for Emacs APIs, it does not > handle asynchronous calls too well. Indeed, this is a serious problem for eldoc. But it should be fairly easy to address. E.g. we could decide that instead of returning a string, eldoc-documentation-function can return a function which is then called with a "continuation". Or we could introduce a new eldoc-async-documentation-function. > 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. > this. In the case of auto-completion, this is a lot more complicated. Yes, asynchrony and c-a-p-f can be more problematic. For completion-at-point, it's not really a problem because by the time we use c-a-p-f we know we want the answer "right now". But for Company we'd instead want to support asynchrony so the external process can take a little while to return the "current" completion candidates while the user keeps on typing. If the candidates arrive too late (the user has moved on to greener pastures), then just drop the result, and otherwise display it. 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. Stefan