[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...)
Date: Sun, 16 Feb 2014 03:47:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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?

reply via email to

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