unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Eric M. Ludlam" <ericludlam@gmail.com>
To: Leo <sdl.web@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Does CEDET work?
Date: Wed, 18 Apr 2012 21:50:30 -0400	[thread overview]
Message-ID: <4F8F6F66.3080007@siege-engine.com> (raw)
In-Reply-To: <87sjg07m94.fsf@gmail.com>

On 04/18/2012 05:39 PM, Leo wrote:
> On 2012-04-19 06:05 +0800, joakim@verona.se wrote:
>> This type of humour is sometimes funny in #emacs, but does not translate
>> at all well to emacs-develop where people are trying to be productive.
>
> Indeed. But the question is genuine. I have been comparing two python
> editing environments: PyCharm (commercial) and Emacs. And the former got
> decent parser for everything remotely related to python: js, html, xml,
> css, sass, sql, coffeescript etc. etc not to mention python specific
> stuff. I can appreciate such an intelligent environment and the enormous
> productivity it enables.

CEDET suffers in that it is pretty good in a fairly narrow band, ie - 
the band that I've worked in, and a few areas other people have helped 
with.  As I wrote it, I wanted to create a framework to make sure new 
support for these tasks could be added for other languages/projects. 
Sort of the way you always use GUD to write a debugger, you can use 
CEDET to do project management, parsing, or code gen.

Anyway, I think folks pick up CEDET, see a reference to their favorite 
language, and the most complex feature (smart completion) doesn't work 
as they expected because they are outside the well supported band, and 
configuring it is too much of a challenge because they have never seen 
it work in areas where it does work well to even know what the reward is.

Python is a fine example.  There's a pretty good parser, but if it can't 
find system libraries, and if it doesn't understand a typical python 
project structure, then the smart completion is kind of lacking. 
Hooking in all the external tool support in really needs someone who 
loves the language to stick their nose in to complete the feature.

I recently picked up Android programming as a hobby to see what I could 
do, and immediately found the lack of direct support for Android 
projects and java system libraries meant very few features worked.  It 
took a little while to build up the support, teaching CEDET where 
directories are, and getting system libraries hooked so I can extract 
symbols from them, and tying it all into smart completion.  Now it will 
complete almost anything in Java with android libraries.  Nifty, but 
also took a couple days since I'm not an expert in either Android or 
Java.  Arduino support went a lot quicker since the language was C++, 
but their command line Make system was a bit baffling to me for a while.

Anyway, there is the beginnings of support for many languages, but a 
combination of developing project support and hooking in external tools 
to derive system symbol libraries is needed to really make the system 
work well.  As has been said many times, configuring CEDET can be a real 
challenge.  That's why tools that do work well often are very 
persnickety about how you lay out your project.  It is rare for a tool 
to try and "just work" in some arbitrary code blob the way CEDET does.

Eric



  reply	other threads:[~2012-04-19  1:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 21:36 Does CEDET work? Jordi Gutiérrez Hermoso
2012-04-18 22:05 ` joakim
2012-04-18 21:39   ` Leo
2012-04-19  1:50     ` Eric M. Ludlam [this message]
2012-04-19  2:03     ` Óscar Fuentes
2012-04-19  5:47       ` Andreas Röhler
2012-04-19  1:35 ` Tom Tromey
2012-04-19  4:29 ` Les Harris
2012-04-19  4:59   ` Jambunathan K
2012-04-19  5:22     ` Les Harris
2012-04-19 15:52       ` Jordi Gutiérrez Hermoso
2012-04-19 17:22         ` Aneesh Kumar K.V
2012-04-23 12:50   ` Nix
2012-04-26 18:14   ` Philipp Haselwarter
2012-04-26 18:26     ` Lennart Borgman
2012-04-26 19:13       ` Philipp Haselwarter
2012-04-26 19:17         ` Lennart Borgman
2012-04-26 23:36           ` Eric M. Ludlam
2012-04-26 23:58             ` Lennart Borgman
2012-04-26 18:42     ` David Engster
2012-04-26 21:11     ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=4F8F6F66.3080007@siege-engine.com \
    --to=ericludlam@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=sdl.web@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).