Re: IDE

[Eric Ludlam]

On 10/14/2015 04:09 AM, David Kastrup wrote:
> Eric Ludlam <address@hidden> writes:
>
> > On 10/13/2015 12:28 PM, David Kastrup wrote:
> > Based on the many emails I've seen on the topic, I suspect the answer 
> > is: * It is hard to configure (ie - setting up project files, include 
> > paths, or whatever.) * Specific implementations are incomplete (ie - 
> > c++ || other parser is imperfect, the project system doesn't 
> > implement some feature, etc) * It is compared against better staffed 
> > tools 
> I got rid of it because it tended to eat all my CPU repeatedly digging
> through buffers and files in the background.  I don't want some tool to
> go treasure-hunting for hours in my directories without concrete cause,
> then restart for inscrutable reasons.
>
> It had its own idea of projects not matching the projects I was working
> with, and it's an absolute no-go for Emacs to meddle with project
> organization: I want to be able to jump in with Emacs into any project
> without any pre- or post-configuration.
Thanks for the diverse feedback.

The need to move your files into some new structure is something I've 
always avoided.  There is a "do it for you" project structure if you 
don't care, and several other types that just uses what you have, and 
can detect a bunch of variants without leaving its own files behind.

> Maybe that's a decisive difference between what people got to expect
> from an IDE and I expect from Emacs: if someone develops stuff in Visual
> C++, everybody in the project is expected to use the project
> organization tools of the Visual C++ IDE.  But I don't want my choice of
> Emacs as an editor bleed all over a project.
>
> Now you'll say that EDE (or Semantic, or whatever other component) is
> entirely optional but it's hard to figure out just what the relations of
> the various parts of CEDET are.  If you want to just work with the code
> you have and not get stuff messed up, at some point of time it's easier
> to just forego the whole inscrutable package and simplify one's life

The puzzle for me here is that while the different pieces are 
technically independent, the more complex tasks, such as completion, 
depend on the other tools doing their job.  Good smart completion 
depends on a knowledge of a project's structure to find headers (C/C++), 
and it also depends on rummaging around in your files to find the needed 
symbols.

AFAIK, every smart completion engine out there has the same dependency.  
There are plenty of others that don't, like Global which just finds 
what's there and makes the most of it, but it isn't smart completion.

I suspect what you'd really like is to say "yeah, I'd like some smart 
completion with a side of API doc", and have an auto-configure thingy do 
the rest.  Sounds great!  To make that happen though, we need Emacs to 
be taught how to detect your files and rummage through them to make it 
happen.  If you work on code of a style I or other contributors never 
worked on, it probably isn't in CEDET.

Pulling in external tools like gcc, clang, whatever to do the work is a 
great way to make that happen as it pushes the CPU work off of Emacs' 
thread, and in some cases brings knowledge of the project along with 
it.  Doing that type of integration can be done with CEDET's framework, 
or independent of it.  I am not advocating to not do that type of 
integration, but to consider doing it in CEDET's framework because:

a) it will be easier than starting from scratch
b) doesn't preclude other types of integration later

On 10/14/2015 06:47 AM, Dmitry Gutov wrote:
> My already-stated impression is that it's over-specialized and tightly 
> coupled.

There are definitely dependencies.  I don't think it is 
over-specialized, but perhaps overly-generalized.  Every layer was set 
up so new languages, modes, projects, whatever can be slotted into the 
system.  The tendency is that many are not complete which lends itself 
to disappointment.  This is not uncommon in Emacs. There are lots of 
modes floating around with no indentation, poor syntax tables and 
incomplete highlighting.

> Not saying that the problem domain is easy, but being able to use 
> different pieces of the solution separately would go a long way 
> towards alleviating the complaint that certain other parts are 
> incomplete.

I agree, this would be nice.

> Especially if it were easier to swap in different solutions for some 
> of those parts (and do entirely without some others), and do that in 
> not too many lines, all as part of the user's configuration.

It is possible to swap in different solutions (under the CEDET 
framework) but in many cases, there is currently only one solution.

In these conversations it is hard to distinguish if the (usually valid) 
criticism are about CEDET the framework, or about various 
implementations under CEDET.

It is also hard since I don't really have time to address the issues raised.

Eric