Re: IDE

[David Engster]

Dmitry Gutov writes:
> 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.

Well, all I can say is it works well.

>> 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.

The database wouldn't be much of a problem, I think. It's just
incredibly hard, if not impossible, to parse such a dynamic language
statically. For Javascript, I wrote a small semanticdb backend to query
a running Firefox process through mozrepl. That worked pretty well for
getting completions on stuff like jQuery.

>> 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.

I fully agree. The above mentioned mozrepl-binding worked together with
our small Javascript parser.

>> 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

It's a matter of someone implementing overloads. And such a
implementation could be used from any other languages that has
overloading on function arguments, which is pretty common.

> 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.

There are a lot of similarities in C-like languages. Also, any
OOP-language will have something like classes, parents, methods,
attributes. But yes, type inference and dynamic languages make things
more complicated. Querying an external REPL or some tool that analyzes
the code would often be necessary.

> Type analysis is often at least as complex as parsing (if not
> more).

For C++11, it has become more complex, which is why I will indeed ask an
external tool for type information. Since such a tool will have to build
the AST anyway, it will provide that as well.

> 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.

Yes, of course.

To be honest, I mostly lost track about what is actually discussed
here. I just took offense at John's "if CEDET was the answer we wouldn't
still be asking questions" and avoiding a "CEDET2", like the CEDET we
have in core is a failure.

CEDET tries to walk a narrow path, trying to provide IDE-like features
without Emacs actually becoming a "typical IDE". The IDEs out there have
it easier, as they usually force you into organizing your projects in a
certain way, and they usually target only one language (or language
family).

-David