emacs-devel
[Top][All Lists]
Advanced

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

Re: IDE


From: Óscar Fuentes
Subject: Re: IDE
Date: Tue, 27 Oct 2015 00:06:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

> On 10/27/2015 12:09 AM, Óscar Fuentes wrote:
>
>>> And the subject of this thread is "IDE". Modern IDEs do know stuff.
>>
>> I was addressing the specific sub-topic about TAGS.
>
> That subtopic started exactly with complaint that TAGS only allow for
> "jump to definition". Then someone argued that no, you can store
> anything what you like in them, we discussed that a bit, and here
> you've come to repeat the beginning: "For references, TAGS is of
> little help".

Sorry, I jumped into the middle of the thread.

>> For knowing stuff you need tools which are as sophisticated as the
>> language they are working with, and there is no medium term solution for
>> that requirement as far as Emacs core is concerned on the C++ realm,
>> probably Java as well.
>
> There can be some middle ground.

If by "middle ground" you refer to something that gives the right result
90% of the time when there are external packages that gives the right
result 100% of the time, that middle ground is a waste of time by the
Emacs core hackers.

> From what I've seen of GNU Global
> (admittedly not too much), it's better for both "find definitions" and
> "find references" than TAGS.
>
> Even in C++ and Java it's not too hard to implement a reasonably
> accurate parser that will index definitions. Recognizing references
> accurately is more of a problem (for now we indeed use Grep or similar
> tools).

Definitions can be tricky in C++, if you wish to distinguish the case
where multiple namespaces or classes defines the same keyword and you
expect from Emacs to jump to the correct definition, deduces from the
context. In that case you need a parser that is good enough to act as a
compiler front-end.

>> There are external Emacs packages that are on
>> track for solving this problem, and an increasing number of features are
>> being implemented around those external packages.
>
> What Emacs can do is provide a common interface those external
> packages to hook into. Like progmodes/xref.el, for example.

Trying to find a common ground on current use cases is difficult enough.
Anticipating future requirements is almost impossible. Good luck with
that.

[snip]




reply via email to

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