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: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Fri, 28 Feb 2014 10:51:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     Anyway, Stefan gave is OK on libclang usage, 
>
> That statement seems to be a misunderstanding.  My decision, as head
> of the GNU Project, is that we will not install anything in Emacs or
> ELPA that uses clang or LLVM.

I understood it so far as "that does not specifically use clang or
LLVM".  Like with supporting Windows, I would have guessed that we are
not going to introduce functionality that _requires_ the use of clang or
LLVM but would not object to functionality supporting several compilers
in a way that does not lead people to _prefer_ clang/LLVM over GCC.

I think any state where there would be no obvious incentive to install
clang/LLVM if your end goal was to compile software using GCC would be
fine.

Now the case of Windows is obviously different (as Windows is
proprietary and is more of a platform rather than a tool), but I would
guess that it would be reasonable to apply the same logic here.

Is that a correct interpretation?

> You can use CEDET, you can use GCC, you can use both, or you
> can use something else.  But not clang or LLVM.
>
> This decision is necessary for achieving more the goal
> of the GNU Project, which is to give computer users' freedom
> in their computing in general -- not just in their text editing.

Well, our usual stance was more or less that there is nothing wrong with
bringing free systems into the reach of people using some proprietary
software as long as we are not responsible for making the proprietary
software more desirable than its free counterpart.

While supporting non-copyleft free software is basically implicitly
supporting proprietary forks of it, I don't see that we need to apply
stricter rules to the non-copyleft free software itself than to the
proprietary versions.

So far, I did not see that we did.  And I consider it important that we
get this point cleared up as it will have quite a bit of impact on the
motivation of those working on GCC-based support of completion in Emacs
as well if they know in advance whether this feature will have to be
GCC-only or can be extended to include other compilers once the
GCC-based support is solid and convincing.

-- 
David Kastrup




reply via email to

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