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

[Dmitry Gutov <dgutov@yandex.ru>]

On 14.02.2014 20:30, Eli Zaretskii wrote:
> I think your expectations are a bit exaggerated.  You cannot possibly
> expect of anyone who offers some idea to implement it.  People
> implement ideas because they have an itch to scratch, not because they
> just had the idea.

Okay, never mind. Guess my phrasing was too broad.

> First, C is a really simple language, and compilers nowadays are good
> at diagnosing mistakes.

People like to say that, but C being simple and having a weak typing 
system just means one has to learn more things beyond the language 
syntax itself.

> But even if you decide not to go that way, there are a lot of place to
> contribute to the design and the Lisp portions of the implementation.
> Even just formulating the requirements is a huge step forward, IMO.

Most of the requirements for multiple mode support have been discussed 
over the years, and the parent discussion has some details that make the 
picture clearer, at least for me. If you think that's insufficient, 
please feel free to ask questions, or suggest another format for 
recording the requirements.

> Actually, I don't see many new contributors that do it in Lisp,
> either.  Sure, there's a lot of code being committed every day, but
> awfully few features that really advance forward Emacs as the
> programming environment.

You may want to look at the Emacs community at large, not limited to the 
core. There are a lot of packages created and added to MELPA, every week.

> E.g., witness the lack of any significant
> progress in adding IDE features.

I guess that depends on what features you expect.

It's true that CEDET hasn't seen a lot of progress feature-wise lately, 
but that's not very surprising: it's complex, it's relatively hard to 
set up for a novice, it has a weird separation of extra features between 
the versions in Emacs and its own trunk, and it's not really suitable 
for dynamic languages, or languages with type inference. AFAIK, that is.

As far as code completion interface goes, Company development continues.

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

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.

One feature that has seen less attention is refactoring, but there 
already are a few packages providing simplistic (and some, even more 
complex) refactorings: js2-refactor, ruby-refactor, clj-refactor, traad 
and others.

What other features are missing? Class diagrams?