Re: IDE

[Eric Ludlam]

On 10/13/2015 09:02 AM, Lluís wrote:
> > Let's not reiterate past discussions: you forget CEDET.
> Just thinking out loud: it seems to me that many people forget that CEDET is,
> from my understanding, a framework for writing tools first, and a set of such
> example tools later.

Thanks for the reminder.  I forgot to bring that part up in this 
iteration of the conversation.

> > >And if anyone_really_  cares about supporting C/C++, they should be
> > >working with and on GCC's libcc1, which is available for quite some
> > >time already.
> If this is the libgcc1 you mean [1], I'm not sure it's suitable for code
> completion. Instead, GCC should be modified to hook into the frontend parser or
> the generic AST and then parsing that, which is no small feat. Fortunately,
> hooking is already possible using GCC plugins [2].
>
> [1]http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
> [2]http://www.codesynthesis.com/~boris/blog/2010/05/03/parsing-cxx-with-gcc-plugin-part-1/
>
> With this, it's a relatively easy (but time-consuming) task to build an external
> tool that parses files on-demand. The ideal would be some kind of persistent
> daemon+database, as was discussed in the CEDET list quite some time ago, but
> that's an entirely different story.

Yes, I remember those discussions. I was able to put in examples of an 
external parser by integrating exuberent ctags which is a bit weak for 
CEDET needs, but was never able to get any help figuring out how to make 
gcc or any other compiler provide the data I wanted.  I tried some stuff 
with using debug symbols and gdb, but that was a flop.  The ectags 
example showed marked performance improvement by delegating parsing 
outside the Emacs process.

A second area was an external database for looking up symbols.  I pulled 
in GNU Global and a couple others as proof of concept examples, but 
never got around to anything custom, as that was a bit bigger task.  The 
lack of an external parser to use with it made the project more daunting.

Eric