Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...)

[Eli Zaretskii <eliz@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

> Date: Sun, 16 Feb 2014 18:07:12 +0100
> From: Jorgen Schaefer <forcer@forcix.cx>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, emacs-devel@gnu.org
> 
> On Sun, 16 Feb 2014 18:45:36 +0200
> Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > But how about starting with those GUI code folding
> > decorations like every IDE nowadays has, while Emacs doesn't?  (ECB
> > comes close, but why shouldn't an Emacs user have that out of the box,
> > especially when Speedbar does something very similar for ages?)
> 
> Assuming you mean something like this:
> 
> http://pythonthusiast.pythonblogs.com/gallery/230/pycharm2.PNG

Or like this:


[-- Attachment #2: VS_Outlining.png --]
[-- Type: image/png, Size: 19147 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2524 bytes --]


> The whole code folding infrastructure in Emacs needs work, really. The
> problem, as often with Emacs, is not that it wouldn't exist at all, but
> that there are two dozen solutions that all have different
> shortcomings.

Then here's a clear bunch of todo items, right?  I hope someone will
volunteer.

> > > Despite certain expectations that everything is better when written
> > > in Emacs Lisp, context-dependent code completion and documentation
> > > display support is usually delegated to an external process, and
> > > there are relatively new packages that use editor-agnostic
> > > services: Jedi for Python, nREPL for Clojure, Tern for JavaScript,
> > > OmniSharp for C#.
> > 
> > Where's their integration with Emacs, though?
> 
> Jedi: https://github.com/tkf/emacs-jedi
> Jedi and Rope: https://github.com/jorgenschaefer/elpy
> nrepl: https://github.com/technomancy/nrepl.el (and others)
> tern: https://github.com/marijnh/tern/tree/master/emacs (and others)
> OmniSharp: https://github.com/sp3ctum/omnisharp-emacs (apparently)

Why aren't they part of Emacs?

> As I said in the thread you mentioned, the problem is not that these
> extensions wouldn't exist for Emacs, it's that each and every one of
> them reinvents most of the wheel to get similar features to Emacs.

Bringing them into Emacs bundle is a significant first step towards
solving the deficiencies, since Emacs maintainers will work with the
authors to fix them, and will continue maintaining them through the
years.  If they are left outside, they will continue being on the
fringe.

> > > There are even several packages that provide support for C/C++ code 
> > > completion using Clang or libclang. They are older, though, than
> > > the ones mentioned above.
> > 
> > And where's _their_ integration with Emacs?
> 
> The integration was declined on this list because Emacs should prefer
> gcc over clang to protect user's freedoms, and gcc does not provide such
> features.

GCC supports plugins, so it should be possible to do the same.

Or start with CEDET and Semantic, as was already suggested several
times.

In any case, clinging with clang clearly makes no sense, if we want
these features in Emacs.

> > Yes, refactoring is very important, and we should have it before we
> > can call ourselves IDE.
> 
> Various Rope-based extensions for Emacs (ropemacs, elpy) offer access to
> Rope's Python refactoring tools. It's still short of "real"
> integration, though, but the first steps are there.

Bring those into Emacs, please.