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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 16 Feb 2014 03:47:06 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: dak@gnu.org, emacs-devel@gnu.org
> 
> > 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.

Not sure what you mean.  Also, how is this different from Lisp?

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

What I would suggest is to collect the requirements in a single list,
and file a wishlist bug report with them.  I wouldn't expect
interested people, if there are any, to glean the requirements from
that longish discussion.

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

Yes, everybody plays with their favorite toys.  But how does this
advance Emacs, and do we even have a roadmap for where we want it to
go?

> > E.g., witness the lack of any significant
> > progress in adding IDE features.
> 
> I guess that depends on what features you expect.

There was a discussion about this some time ago, although I cannot
find it now.  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?)

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

Then the immediate task would be to make it simpler to set up and
suitable for those languages.  _That_ would really move Emacs forward,
towards a point where, hopefully, it will once again be relevant for
modern development paradigm and provide what programmers expect.

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

I hope this will some day be bundled with Emacs.  (I also hope we
rename it to something more palatable before that happens, because
having newbies learn that completion-related features are called
"company-SOMETHING" is voluntarily falling into the same trap as with
"kill/yank" vs "cut/paste" and "frame" vs "window", except that this
time we have no excuses.)

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

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

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

Yes, refactoring is very important, and we should have it before we
can call ourselves IDE.

> What other features are missing? Class diagrams?

Yes, that too.