Re: Is EDE only intended to be used with languages which /require/ a 'compile' step? [was: Re: IDE]

[Aaron Ecay <aaronecay@gmail.com>]

2015ko urriak 22an, Alexis-ek idatzi zuen:
> 
> Eric Ludlam <eric@siege-engine.com> writes:
> 
>> EDE's original intent was for handling compilation of compiled 
>> languages.  Since then, it also forms a base for anything that 
>> wants to  organize code into a 'project' so that support code 
>> can say "what is the  current project" and then "does that 
>> project have a language specific  detail I can use".  It doesn't 
>> really matter if it compiles or not.
> 
> Thank you for clarifying! i would like to suggest that the EDE 
> documentation be modified to reflect this.

+1.  I read the EDE info documentation several years ago, and had the
impression that EDE (and CEDET more broadly) would not work well for me
because I never use compiled languages, and (almost) never Makefiles.  I
got the same impression from the “Projects” section on the CEDET homepage,
which says it can recognize Makefile-based projects and other projects
“such as the Emacs sources, the Linux kernel, or any project built using
Automake.”  Nothing about JS, Python, or other dynamic languages (or
even Java).

There have been several threads about IDE-like features in the past
where CEDET has been mentioned, but this is the first one that has
actually allowed me to understand how it might actually be useful for
dynamic languages (even if that requires more extensions that don’t
exist yet).

In a related vein, it would be nice to see something about “why CEDET”
from the perspective of advanced users/developers.  There are lots of
projects that create development environments for Emacs in dynamic
languages: elpy for python, ESS for R, cider for clojure, etc.  These
combine “foolproof” setup of various emacs features (which-func, imenu,
repl interaction, completion, ...) with a tool that analyzes the source
and feeds information back to emacs.  I often find these tools a little
annoying, because they all work slightly differently, and sometimes
don’t obey emacs conventions for customization (e.g. using hard-coded
values instead of hooks and keymaps).

It would be good if someone(s) familiar with CEDET could articulate the
benefits of implementing these types of systems with CEDET.  It’s a
worthy goal to eventually transfer many of the features of these systems
to CEDET, ideally relying on the work that these projects have already
done on the external tooling.  This document could serve as a roadmap
for that work, as well as helping convince new projects to use CEDET.

Thanks,

-- 
Aaron Ecay