Re: IDE

[Dmitry Gutov]

On 10/11/2015 08:37 PM, Eric Ludlam wrote:
> If you have a tool that parses already (such as exuberent
> CTags), you can instead just start at the high level tagging parser and
> skip all the lower level stuff.

Right.

> If you have an existing completion engine for cases where you happen to
> have an interpreter with completion, or something else, you can just
> override the completion engine directly.

You haven't answered the question about the advantage of doing it this 
way. If I override the completion engine directly, what main benefits of 
using CEDET are left? I mean, are they worth working on defining a 
grammar for the language, and keeping it up-to-date. A grammar can take 
a lot of effort by itself.

> The srecode tool does this,
> and there is an experimental clang version in CEDET's repository as well.

srecode overrides the completion engine? Why?

> Having overrides at all 3 levels is the best, since different tools ask
> for different features, but it is not necessary as there is backup
> implementation for the higher level features.

I agree that, in general, having overridable implementations is pretty 
great.

> Of course.  For strongly typed languages the problems are deterministic
> so it's possible.  For dynamic languages, they usually provide something
> you can ask.  It's just a matter of integration.
>
> I enjoy working on puzzles like this, but for me it is a matter of free
> time.  Kids, job, etc get in the way.

My impression is that nobody has solved this puzzle for any of the 
dynamic languages that CEDET aims to support. Which is not a definitive 
evidence either way, but it's pretty discouraging for a person 
interested in implementing better support for a dynamic language they're 
interested in.

> Semantic has the information to differentiate between two methods of
> different types.  There are still a few short-cuts in the completion
> engine  where it could do a little more to disambiguate.  There is a
> function to '-select-best-tag' in the analyzer, but at the end, it just
> grabs the first element from the list of possibilities.  If you have a
> particular use case in mind, it would good to have a simple example that
> shows what it is and maybe it will be easy to update.

Try this: https://gist.github.com/dgutov/19c45ef43d1c90b96483

I should get "a" and "b" as completions, but instead I get "c" and "d".

> This is a matter of time and desire.  For the code I've been writing
> lately (arduino hobby stuff), it has been more than sufficient. David
> was interested in handling templates and was able to add support for
> that.  If someone wants it to handle something new, the data is there to
> do it.

Yes, templates are pretty important. And complex. I don't know if 
re-implementing the code to understand them in Elisp is the way to go.

> What's missing is someone taking the time to start building the logic to
> use semantic to pull buffers apart, and srecode to re-write the code.

All right. So we could try to use Srecode interface for refactoring.