Re: New maintainer

[David Kastrup <dak@gnu.org>]

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>> Jay Belanger <jay.p.belanger@gmail.com> 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.

That interpretation is not supported by the mailing list history.  In
particular, there were (and still are) conscious restrictions to the
amount of information GCC may provide in a generic format and/or via a
generic plugin interface since such generic mechanisms define the
"application as a whole" border beyond which copyright and consequently
the GPL does not reach.  If Emacs now provided functionality using Clang
that has been intentionally omitted from or restricted in GCC, this
would be self-defeating.

So yes, in that respect GCC _does_ determine the least upper bound of
functionality.  This has by far been the most heatedly debated influence
of GPL-supporting strategic decisions on this mailing list in the last
years and has even be covered in "Linux Weekly News" several times
(searching for "Emacs" in their archives will likely pull up
references).  The way to make progress in such areas may thus be the
most frustrating part of Emacs maintainership as it requires pushing for
changes with GCC in lockstep, and in this case not just functional
changes (which already provide a challenge and thus can be expected to
move forward rather slower than faster) but also strategic direction
changes.

If you want to go there, it might be an idea starting with the
Ada-specific GCC fork which probably went under the radar with its
option exporting the parse tree.  Working on a good proof-of-concept
using that is probably the most convincing argument you can make.

The good news is likely that this is about the most you can expect in
the area of influence of the GPL and associated policies on Emacs, so if
you make yourself acquainted with the happenings there, you have seen
the practical side of the limitations due to licensing.

-- 
David Kastrup