Re: Emacs contributions, C and Lisp

[Dmitry Gutov]

On 16.02.2014 19:36, Eli Zaretskii wrote:
> > 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?

Here's an obvious answer: CA.

They are available through package archives, though.

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

I'd like the see the wheels enumerated.

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

Hopefully, this is something that would accompany bringing a package 
into GNU ELPA, too.

> If they are left outside, they will continue being on the fringe.

I don't know about being on the fringe. The ones above are fairly popular.

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

And this brings us back to contributors interested in writing C code. 
Moreover, in this case, to duplicate functionality that's already 
available for most users anyway.

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

Do we? Until there are no big problems to solve in Emacs left, I'd be 
pretty comfortable with recommending users who want better completion in 
C/C++/ObjC to install a third-party package.