[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
- Re: New maintainer, (continued)
- Re: New maintainer, John Wiegley, 2015/10/08
- Re: New maintainer, Richard Stallman, 2015/10/08
- Re: New maintainer, John Wiegley, 2015/10/08
- Re: New maintainer, Richard Stallman, 2015/10/08
- Re: New maintainer, John Wiegley, 2015/10/08
- Re: New maintainer, Dmitry Gutov, 2015/10/08
- Re: New maintainer, Jay Belanger, 2015/10/08
- Re: New maintainer, Dmitry Gutov, 2015/10/08
- Re: New maintainer, Jay Belanger, 2015/10/08
- Re: New maintainer, Dmitry Gutov, 2015/10/08
- Re: New maintainer,
John Wiegley <=
- Re: New maintainer, David Kastrup, 2015/10/08
- Re: New maintainer, David Engster, 2015/10/08
- Re: New maintainer, John Wiegley, 2015/10/08
- Re: New maintainer, Jay Belanger, 2015/10/08
- Re: New maintainer, David Kastrup, 2015/10/08
- Re: New maintainer, Karl Fogel, 2015/10/08
- Re: New maintainer, David Kastrup, 2015/10/08
- Re: New maintainer, John Wiegley, 2015/10/08
- Re: New maintainer, Karl Fogel, 2015/10/08
- Re: New maintainer, Phillip Lord, 2015/10/08