emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDE


From: David Engster
Subject: Re: IDE
Date: Sun, 18 Oct 2015 13:56:11 +0200
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux)

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

In dynamic languages, you would mostly have tags with no specific type.

>> 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 is only upstream, and I wouldn't be surprised if it is broken by now
due to changes in mozrepl (this is why I don't like depending on
external binaries). I don't code Javascript anymore.

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

Well, it's not like a bunch of people are hacking on the C
parser. Several things happened:

- Emacs switched to git, so CEDET had to switch as well, which broke my
  merge setup. I still need to repair it, which is extremely boring
  work.

- CEDET does not work with Emacs25 due to large changes in
  EIEIO. Someone has to fix that as well. Again: extremely boring work.

- This gcc-AST discussion.

- New kid.

- In general, hacking Emacs isn't as much fun as it used to be.

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

Which is why Semantic allows to tweak pretty much any part through
mode-local overrides.

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

Of course. That's the goal of CEDET. If it had just focused on C/C++, it
would be simpler.

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

Yes. If people want to hook in Eclim or whatever, that's fine be me. But
it's always the same thing: Those people are *only* iterested in Java,
and they don't want to bother with the bigger picture. This is exactly
why we have a plethora of solutions for different languages at the
moment.

> Not sure about things about Objective-C land.

It's deserted and people move to Swift 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.

Maybe.

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

Yes, and do you know how the Jetbrains guys achieve this? They have an
extensive framework for writing grammars, lexers, etc. Those guys are
weird!

> 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

Ever tried to load some random make-based C++ project into Visual C++?

-David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]