emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs contributions, C and Lisp


From: Juanma Barranquero
Subject: Re: Emacs contributions, C and Lisp
Date: Fri, 28 Feb 2014 22:48:39 +0100

On Fri, Feb 28, 2014 at 9:53 PM, David Kastrup <address@hidden> wrote:

> I am not necessarily describing my own position here.

OK, you're right. Sorry if I misrepresented your position.

> I agree with the
> position of Richard in as far that I would consider it a shame if Emacs
> had to rely on LLVM to provide a useful environment for writing code to
> be compiled with GCC.

But this is not a binary, now-or-never issue. Even if, in some cases,
Emacs had to rely on LLVM, that would change as soon as GCC provided
equivalent support.

> Richard's position as far as I understand is not "we don't want
> compiler-supported completion in Emacs" but rather "we don't want
> completion in Emacs that is only supported by using LLVM".

That can be fixed (for some values of "fixed") by adding compiler
support for completion to GCC. The fact that LLVM has it already, and
that some Emacs modes could be written to support it, does not
preclude extending GCC or creating packages to interact with it (or
extending the LLVM-related ones to support both).

> Whether or
> not one wants to consider relying on LLVM bad politically, it means that
> Emacs will be constrained to support only languages and language
> dialects at the choice of LLVM developers.

I don't see it, really. That's a bit like saying that, because VC was
written to support RCS and CVS, it will forever be constrained by the
design decissions of CVS developers. And yet it has been extended to
grok Subversion, arch, Bazaar, git and Mercurial. I fail to see how "a
mode supports LLVM" turns into "depends on LLVM and nothing more,
forever". The only thing that would preclude these new modes to also
be able to use GCC is if GCC is never extended to provide that
facilities, and in that case, we are in deep trouble, because C++
developers will eventually turn to the tools that make their lives
easier.

> At any rate, given the nature of this decision, any attempt to change it
> would have to be based on bringing previously unconsidered facts to the
> attention of Richard.  "I come to a different conclusion based on the
> same information" is not going to help.

Yes, sure. I'm not trying to change anyone's mind, just trying to
understand the differente issues.

   J



reply via email to

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