Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/17/2015 06:26 PM, David Engster wrote:

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

Maybe not the database, but the "tag" value is used in many places in 
Semantic. I'd want to be able to use them for, say, JavaScript as well. 
For instance, in semantic-symref, not just for completions.

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

I'll have to check it out later.

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

I'm sure it can be implemented in Elisp, just surprised it hasn't been 
taken care of since a similar example came came up 6 (or 12?) months 
ago, in a Clang-related discussion.

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

C-like languages - probably, but every one also has tiny peculiarities 
which have to be handled in a different way.

But Emacs users are a diverse bunch, and for many the draw is in being 
able to use many different languages, including very young ones. So a 
general IDE solution should anticipate having to handle different type 
systems.

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

I'm glad we agree on this. But Java has also become more complex (since 
1.5, maybe?), and Java 8 added lambdas, which allow omitting argument 
types. Not sure about things about Objective-C land.

But otherwise, if it'll be common to use an external tool for type 
resolution, and even parsing the buffer contents, maybe at some point 
you'll deprecate Wisent grammars. Or use, say, a very simplified format 
for them, only what's strictly necessary to find the names and 
boundaries of tags.

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

Personally, I'm happy discussing and figuring out the current state of 
affairs, so that our common understanding goes further than "CEDET 
didn't live up to its promises" or "don't throw out CEDET, we've got 
nothing better".

The EDE subthread also brought up some ideas for project.el.

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

That's not really true. IntelliJ IDEA supports a big swath of languages, 
and my colleagues use it successfully for our "non-standard" Ruby 
projects (no Rails), and also with JS and different markup languages. 
But of course you have different challenges with C++, and the JetBrains 
team has more manpower anyway.

But I'd be ecstatic to even have a consistent UI for features that VS 
Code (smaller cousin of Visual Studio) touts here: 
https://code.visualstudio.com/docs/editor/editingevolved