Re: Is intellisense features integration in Emacs technically possible?

[Stefan Monnier]

> 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