all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Eric M. Ludlam" <eric@siege-engine.com>
To: emacs-devel@gnu.org
Subject: Re: Is intellisense features integration in Emacs	technically	possible?
Date: Wed, 22 Jan 2014 21:22:50 -0500	[thread overview]
Message-ID: <52E07CFA.2090206@siege-engine.com> (raw)
In-Reply-To: <877g9shqms.fsf@newcastle.ac.uk>

On 01/22/2014 12:29 PM, Phillip Lord wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
>>> A better way is to build on the hard work of other and interface
>>> emacs with an external tool.
>>
>> Personally, I think implementing such features via external programs
>> is a terrible design.  It will never be smooth and responsive enough,
>> and on top of that you'd need to track development of those other
>> tools.  And what if they become abandoned some day?
>
>
> I think that it depends on the language. Introspecting over, for
> example, Java would require an awful of elisp, which would be difficult
> to write. Getting Java to do this work is quite a lot less effort.
> Hence, the JDEEs use of Java for this (via bsh). Likewise, Clojure and
> Scala both of which use their own language to do much of the work. Or
> for that matter, common lisp with slime/swank. Or even, for that matter,
> English with aspell. I didn't have a problem with responsiveness with
> any of these.

I don't think it is a good idea to consider the problem of doing smart 
completion in Emacs as "Emacs Lisp VS External library".  It is much 
more advantageous to figure out what each is best at and do that instead.

There are certainly examples on both extremes.  CEDET and Semantic by 
themselves can parse surprisingly large C++ code bases and provide smart 
completion quite accurately, but as the code base grows, it gets slower. 
  It also took a really long time to implement in my spare time in spite 
of the vast amount of help I've gotten from its users.

There are also completion you can implement by passing entire buffers 
into an external parser as explained by Jorgen for Python, and I think 
clang could do something similar.  These were coded more quickly, and 
can provide rapid results.

I think it would be better to have a strong mix between the two.  I am 
of course a bit biased since I've put support for this in CEDET quite a 
while ago.  The premise for those who haven't studied how the smart 
completion engine in CEDET works is pretty simple.  Emacs is in charge 
of basic buffer parsing.  As David explained, it is a simple tagging 
parser, but unlike etags/ctags, it collects much more detailed 
information.   It also has a local context parser, allowing it to find 
local variables, and identify the kind of command the cursor is sitting 
on, such as an assignment, struct dereferences, etc.

Once that basic part is done, the smart completion engine starts looking 
up symbols.  It does this via a series of 'semanticdb' EIEIO objects 
that are associated with the buffer.  With no external program support, 
it uses an all Emacs solution to lookup header files or whatever that 
language uses.  Alternately, there are external programs wrapped up in 
this EIEIO class that can provide the same services.   Thus for Java 
there is a 'javap' service that can find symbols in .jar files to 
provide the answer.

There are many external programs such as GNU Global, idutils, cscope, 
and javap that are already supported, and each provides different levels 
of support based on what they can do.  They all make CEDET faster or 
more accurate when in use.

It is tempting to go with an entirely external solution.  They can 
usually be wrapped up by Emacs in pretty quickly.  There are additional 
advantages aside from smart completion to adding parsing support for a 
language directly to Emacs however.  What CEDET does is place overlays 
in the buffer identifying the tags and their nesting.  Simple queries 
can tell you exactly where you are structurally in a program with no 
regexp calls, searching, or other time-consuming activities.  You can 
use this for breadcrumbs, decorations, named bookmarks, navigation, and 
any kind of function that needs to know where you are by name. 
Semantic also can provide access to the current buffer tag-list at next 
to 0 cost when asked (assuming the idle timers have had a chance to run) 
making think like imenu, which-func, speedbar, and ECB very fast.  It 
seems unlikely an external tool could do all that without quite a bit of 
effort.

Lastly, most parts of CEDET/Semantic's parsing and completion engines 
can be replaced per-mode at almost any level, not just at the database 
level.  As such, if someone really wants to use an external tool to 
parse a buffer or provide completion (2 different operations), it will 
let you do it, and all the existing CEDET tools will then work just fine 
on top of the result.

Eric



  parent reply	other threads:[~2014-01-23  2:22 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21  2:01 Is intellisense features integration in Emacs technically possible? Jorge Araya Navarro
2014-01-21 18:59 ` Tom
2014-01-21 19:29   ` Eli Zaretskii
2014-01-21 19:58     ` Tom
2014-01-22  3:53       ` Eli Zaretskii
2014-01-22  4:36         ` Óscar Fuentes
2014-01-22  6:31           ` David Kastrup
2014-01-22  7:26             ` Stephen J. Turnbull
2014-01-22  8:13               ` David Kastrup
2014-01-22  9:33                 ` Stephen J. Turnbull
2014-01-22 11:02                   ` David Kastrup
2014-01-22 13:35                 ` Stefan Monnier
2014-01-22 16:04               ` Eli Zaretskii
2014-01-23  8:13                 ` Stephen J. Turnbull
2014-01-23  8:44                   ` David Kastrup
2014-01-23 16:19                   ` Eli Zaretskii
2014-01-24  2:57                     ` Stephen J. Turnbull
2014-01-24  7:43                       ` Eli Zaretskii
2014-01-22  8:49           ` Rüdiger Sonderfeld
2014-01-22 11:53             ` Óscar Fuentes
2014-01-22 15:56               ` Eli Zaretskii
2014-01-22 18:46                 ` Stefan Monnier
2014-01-22 19:10                   ` David Engster
2014-01-22 16:52               ` David Engster
2014-01-22 15:59           ` Eli Zaretskii
2014-01-22 16:41           ` David Engster
2014-01-22 17:16             ` Dmitry Gutov
2014-01-22 17:36               ` David Engster
2014-01-22 18:12             ` Óscar Fuentes
2014-01-22 18:34               ` David Engster
2014-01-21 20:03     ` Andreas Röhler
2014-01-22  3:54       ` Eli Zaretskii
2014-01-22  6:28         ` Stephen J. Turnbull
2014-01-22 16:03           ` Eli Zaretskii
2014-01-23  7:54             ` Stephen J. Turnbull
2014-01-22 17:29     ` Phillip Lord
2014-01-22 18:49       ` Jorgen Schaefer
2014-01-23  9:00         ` Andreas Röhler
2014-01-23 19:34           ` Jorgen Schaefer
2014-01-23 13:20         ` Phillip Lord
2014-01-23 15:12           ` Stefan Monnier
2014-01-23 20:56             ` Jorgen Schaefer
2014-01-23 22:13               ` Stefan Monnier
2014-01-23 22:43                 ` Jorgen Schaefer
2014-01-24  1:40                   ` Stefan Monnier
2014-01-24 10:25                     ` Jorgen Schaefer
2014-01-24 12:46                       ` Thien-Thi Nguyen
2014-01-24 13:20                       ` Stefan Monnier
2014-01-25 23:42                     ` Dmitry Gutov
2014-01-24 11:58               ` Phillip Lord
2014-01-25 23:53               ` Dmitry Gutov
2014-01-26 10:15                 ` Jorgen Schaefer
2014-01-26 23:04                   ` Dmitry Gutov
2014-01-23  2:22       ` Eric M. Ludlam [this message]
2014-01-23 13:26         ` Phillip Lord
2014-01-21 19:53   ` David Engster
2014-01-21 20:07     ` Tom
2014-01-21 20:13       ` David Engster
2014-01-21 20:24         ` Tom
2014-01-21 22:50           ` David Engster
2014-01-22  3:55           ` Eli Zaretskii
2014-01-23  9:16             ` Andreas Röhler
2014-01-23 17:17               ` Richard Stallman
     [not found] <mailman.172802.1390363342.10747.emacs-devel@gnu.org>
2014-01-22  7:39 ` Jorge Araya Navarro
2014-01-22 15:39   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52E07CFA.2090206@siege-engine.com \
    --to=eric@siege-engine.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.