emacs-devel
[Top][All Lists]
Advanced

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

Re: New maintainer


From: John Wiegley
Subject: Re: New maintainer
Date: Mon, 05 Oct 2015 13:37:34 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)

>>>>> Jay Belanger <address@hidden> writes:

>>> Maybe I'm misreading it, but it doesn't sound like what Richard meant at
>>> all. I read it as the features have to actually work with GCC ("not just a
>>> theoretical idea") to be included.
>> 
>> The issue is that GCC, in its current state, doesn't provide a certain
>> set a features Emacs can take advantage of, that Clang does.

> That's the point. It sounded like Richard was saying that in that case,
> Emacs shouldn't take advantage of it. How else could

>> If it really works usefully with GCC -- if that is not just a theoretical
>> idea -- then I won't object to its supporting other compilers as well.

> be interpreted?

I interpret him as meaning that the support should not favor non-GCC compilers
in any way, not that GCC should determine the least upper bound on
functionality.

For example, an automobile can be driven by any able-bodied individual. It
does not favor one person over another, because it is adjustable. Both my wife
and I can drive the same cars, always.

A car does, however, favor ability. A better driver will drive any car better
than a worse driver. This does not preclude the worse driver from studying and
becoming better, however. It does not "build in" any advantage that makes one
driver better, no matter what the other driver does.

To me, Emacs is a vehicle for content, and external processes sometimes guide
or drive that content, such as GCC or Clang within a C++ buffer. Emacs should
be adjustable to allow either one to be used. Certainly one may provide better
functionality than the other, but Emacs itself should not favor one over the
other. If GCC ends up excelling Clang as a compiler, its Emacs support should
be capable of excelling Clang as well, without any change necessary from Emacs
to allow this.

If, on the other hand, Clang offered some clever API that was specific to
Clang, and we built support for that API directly into Emacs to allow a better
experience for Clang users, this is what Richard would not allow, according to
what I read.

John



reply via email to

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