Re: Emacs contributions, C and Lisp

[Stephen J. Turnbull]

Jambunathan K writes:

 > Is it about:
 > 
 > 1. Making new features available within Emacs?
 > 
 >    - completion

Yes.

 >    - refactoring

Different posters have different views on that.

 > 2. Making new features through *a specific* means.
 > 
 >    - llvm only
 >    - gcc only

I don't think anybody advocates anything-only at this point.  Some
posters clearly believe LLVM *first* is a good strategy, because it
provides a very detailed description of the semantics of identifiers
out of the box.  However, Richard has declared LLVM may not be used
for development of these features[1], so this issue is moot.

David's point about LLVM support being implicitly LLVM-only is about
the pragmatic outcome of any implementation using LLVM: to some extent
it is very likely to detect LLVM-only C/C++ extensions and provide
appropriate "advice" to Emacs completion, but it would be rather
difficult to serve GCC-only extensions in the same way.  (Did I get
that right this time, David?)  If that is "first", then (at least for
a while) the effect will be LLVM-only in this sense.[2]

 > 3. Improving and stregthening the overall ecosystem.

Always, for any GNU project.  (But beware, Richard deprecates terms
like "ecosystem" and "ecology", I forget exactly why.  Something about
GNU not being an emergent outcome of random evolution, but rather
being designed and organized specifically to support software freedom,
IIRC.)

 >    Hyper-linking to other Free-software out there.

Dunno what you mean by that.

 >    - co-opeation with GCC

Richard wants that, both in this case and as a general matter of
greater unity within GNU as a whole.  I'm not sure if it's realistic
to expect much direct cooperation in this case, the skill sets are
rather different.

 >    - co-opeation with LLVM

Not as a project, that's clearly out because of the licensing.
Importing bits of LLVM code into GNU projects, yes, but not the other
way around.

 > If the focus of this thread is (1), it is better to invite CEDET
 > developers and ask for their inputs.

They're already here, and have been providing their input all along.
The consensus of CEDET supporters seems to be that LLVM tools might
potentially be somewhat more accurate, but that existing CEDET
features plus some additional heuristics should give excellent
results.

 > Shouldn't (1) merit equal attention?

I would say that's David Kastrup's point (except that he would say
that's really the only thing to focus on, use of GCC or CEDET is just
a question of of the inclination of the developers who actually do the
work and the available features).

I suspect David K would also advocate sticking specifically to
"completion" as the feature in question.  Trying to generalize the set
of features to be supported leads pretty quickly to relatively
abstract discussion of the advantages of LLVM's architecture for
building code analysis toolkits (whether in the compiler suite or in
Emacs Lisp), which doesn't help to get people to start working on the
features.

Footnotes: 
[1]  Of course to the extent that LLVM provides the same UI as GCC,
users cannot be prevented for using LLVM instead of GCC.  But no LLVM-
specific options or I/O formats may be supported.

[2]  Don't anybody bother objecting that the common subset of syntax
would serve both LLVM and GCC users.  Neither David nor Richard
objects to that, but they do not consider it a mitigating circumstance.