Re: IDE

[Eric Ludlam <ericludlam@gmail.com>]

On 10/14/2015 11:40 PM, Dmitry Gutov wrote:
> On 10/14/2015 03:05 PM, Eric Ludlam wrote:
>
>> 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.
>
> It seems what we need is a set of "juncture points", which define how 
> separate systems/tools should communicate. That's what xref and 
> project.el are about, for finding locations and project information 
> respectively; everything else in there is mostly for convenience.

Indeed.  That is a similarity.

>> There are definitely dependencies.  I don't think it is
>> over-specialized, but perhaps overly-generalized.
>
> Could be both. But by over-specialized, I mean that a lot of stuff in 
> e.g. ede-project doesn't make sense for many projects. targets, for 
> example. And mailinglist/web-site-url/ftp-site?..
>

There is indeed a bunch of extra not so useful things for all classes in 
the baseclasses.  I would not claim it could not be improved.

Some, such as 'version' and 'name' seem trivial, but become more 
convenient when you start browsing through your open projects.

> I'm also under impression that EDE projects are always one directory 
> deep (and for each subdirectory, you need subprojects). Which reflects 
> the common Makefile usage, but not how projects are structured under 
> many other build systems.
>

Different projects handle this differently.  The original set regarding 
both Automake and Makefile based projects are as you describe.

Last year I simplified a bunch of systems regarding project detection 
and directory hierarchy.  At this point, the 'simplest' project as far 
as setup is the 'generic' project type, one of which finds a project 
based on your VC root (git, cvs, and a few others). It is one project 
covering all the subdirectories.  You can 'customize' the project and 
just fill in the blanks for your build system, include-path and others, 
or just ignore it all.

>> It is possible to swap in different solutions (under the CEDET
>> framework) but in many cases, there is currently only one solution.
>
> Yet still, to even become pluggable, a piece of functionality has to 
> buy into the CEDET fundamentals, like using EIEIO, mode-locals, and 
> CEDET's base classes.
>

Yes.  The structure I started building used traditional emacsy tools for 
handling structure and buffer local behaviours.  The broader the tool 
became, the more of a PITA it was managing all the random lists of 
behaviour differences, and random list references, so I put in missing 
infrastructure.

You will note other tools that wrangle data now use defstruct (now part 
of emacs) or seem to create their own data structure with their own 
accessors, so building such tools is not unusual.  I just tried to make 
mine more generally useful.

Eric