Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/17/2015 03:00 PM, David Engster wrote:
> Eli Zaretskii writes:
>> I'm quite sure CEDET has collected and expressed in code a lot of
>> experience and solutions to many problems that arise in the context of
>> building an IDE.  It's OK to discard that, if we sure that's the
>> proverbial 1st variant everyone throws away, but we need first to be
>> sure we know what we are discarding.

I wouldn't want to discard Semantic, as long as it works better than the 
new solution, in the domain that it's actually targeting. And we should 
learn from its implementation either way.

>  From the discussion so far, I think the main issue at least w.r.t. to
> Semantic is: do you actually want Semantic's tag-based system, or more
> general: do you want quick access to AST information in your buffer?

Not really the main issue. Whether the AST is saved in overlays (and 
thus not refreshed as long as buffer is not modified), for me is an open 
question.

But not many of the existing code assistance tools that are currently 
available, provide that info, at least for dynamic languages. So it 
would be more productive to focus on the things they do provide, and 
grow the internal IDE APIs from that.

Whenever we have a tool that does provide AST dumps at will, or Semantic 
supports the language in question well, it would of course be great to 
use it.

> If I understand Dmitry correctly, he is not really interested in that,
> as for dynamic languages, the AST information is usually missing
> important information (unless you bother to implement a complete
> frontend).

Not sure what you mean exactly by "complete frontend", but it'll often 
be missing anyway. If the current method takes 'foo' as an argument, and 
the method is public, and the method contains 'foo.bar()', often the 
best thing we can tell about 'foo' is that its class contains a method 
called 'bar'.

So at least the Semantic database would have to be extended to work 
meaningfully with tags like that.

> He'd rather call external binaries for complicated stuff like
> completion, and use simpler tools (like pure regexp-based parsing) for
> stuff like font-locking, navigation, folding, etc.

I mentioned SMIE as well. It's a bit more advanced than that.

> Of course, you can
> hook external binaries into Semantic pretty easily, but I can understand
> Dmitry that if he does not need the rest of Semantic, why should he
> bother?

Being able to mix and match would be best, of course.

> Now, I think having AST information in your buffer is great, and I don't
> like depending on external binaries if I don't have to, because I want
> as much as possible in Emacs Lisp. For me, that's what Emacs is about
> and why I still use it in the first place.

My biggest issue with Semantic is that it tries to implement type 
analysis in Elisp, and still hasn't gotten it right even for simple C++ 
code (no classes or templates). Allow me to repeat myself with this: 
https://gist.github.com/dgutov/19c45ef43d1c90b96483

Suggested completions should depend on the argument tee receives ("a" 
and "b" for i, "c" and "d" for l), but they don't.

And I think re-implementing type analysis for each language in Elisp is 
untenable. Correct me if I'm wrong, but you cannot generalize that 
logic: different languages have different type systems, and for each one 
you'd have to write the analysis from scratch.

Type analysis is often at least as complex as parsing (if not more). I'm 
not in any hurry to rewrite e.g. Tern in Elisp, and then keep it up-to-date.

And speaking of more personal reasons, I already have written a code 
assistance tool for Ruby, in Ruby (which is not a Lisp, but still a 
pretty okay language), and smooth integration with whatever APIs we 
choose would be nice.