Re: IDE

[Óscar Fuentes]

Dmitry Gutov <address@hidden> writes:

[snip]

>> 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.
>
> "jump to definition" is about accurately recognizing references. But
> if you're jumping to foo.bar(), and Emacs doesn't know the type of
> 'foo', at least it can show you the definitions of all methods named
> 'bar', and you'll be able to choose for yourself. Using etags-select,
> for instance.

For not-so-big C++ projects, that can be as useless as displaying all
the uses of "bar" on the code base.

>> Trying to find a common ground on current use cases is difficult enough.
>> Anticipating future requirements is almost impossible. Good luck with
>> that.
>
> That's defeatism. Doesn't it bother you that every third-party package
> uses a (sometimes subtly) different set of key bindings, and a
> different way to present the same kinds of information (definitions,
> references, documentation, etc)?

If there is a common pattern, by all means, implement it (on a way that
provides for those subtle differences when they make sense.) But those
packages still need to maintain compatibility with older Emacsen.
Distributing the library on GNU ELPA instead of the Emacs core would
make things better for the external packages, though. But then, what's
the difference from developing the library outside of Emacs core and
working directly with the authors of those external packages? If the
library or API is developed on emacs-devel, is it acceptable to design
it by the requirements of rtags, for instance?