Re: IDE

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Tom <address@hidden>
>> Date: Sat, 10 Oct 2015 04:33:59 +0000 (UTC)
>> 
>> > If it falls short compared with other IDEs, I think this would be a
>> > great area for improvement of Emacs.
>> 
>> The number one requirement by IDE users today is perfect code completion
>> and powerful refactoring support for the language they develop in
>> (Java, C++, etc.).
>> 
>> Any IDE which wants to compete with the popular IDEs must have these,
>> because users find these features much more helpful in development,
>> than keyboard macro support and such.
>> 
>> So if Emacs wants to compete with these tools then it has to have seamless,
>> context aware code completion and refactoring support, and GNU tools
>> has to provide Emacs the necessary information to implement these
>> features.
>
> I agree.  But to have that, the only way is to have motivated
> volunteers step forward and work on these features.  Otherwise we will
> never have them.
>
> Right now, no one is working on that, though everyone is talking.  the
> same as with weather.

Not quite.  IIRC, company-mode integrated (integrates?) the parsing
facilities of Clang with Emacs.  This contribution was rejected (though
I don't have an overview over the actual execution of the rejection)
because of promoting non-GCC compilers.  However, attempts of letting
GCC similarly output AST data were rejected as making it too easy to
support non-free applications (obviously, if Emacs can use GCC for
purposes of syntax analysis from the command line, so can anybody else).
Using the recently admitted GCC plugin interface (previously, plugins
were rejected because they would make supporting non-free applications
too easy) for outputting a full AST was rejected since it would...

You get the drift.  A number of would-be contributors, partly with
solutions or the impetus and skills for creating them, finally went
elsewhere in disgust rather than trying to figure out the maze of which
interoperations between GNU applications were acceptable and which not.

So "no one is working on that, though everyone is talking" is sort of an
unfair characterization because it implies that no one was willing to
put his money and time where his mouth is.

The main problem here is that the default behavior of GNU code is to
refrain from serious interoperability since the GPL (as well as pretty
much anything relying on copyright alone) does not reach across
interoperable interfaces, until such a time that a concrete,
strategically important application requires such interoperability, and
then ways are searched to restrict the interoperability to the
particular combination/application.

So people's hands are bound until a complete plan has been worked out
and/or blessed by Richard and shouting "no one is working on that" is
disingenuous.

I don't think this kind of micromanagement of interoperation can scale.
Lots of worthwhile things come into being by plugging together existing
components in surprising ways and that is an essential component of
academic work and also of software freedom.  Copping out whenever it
gets serious is not going to help free software.

At the same time, the FSF does not turn on a dime.  Which is one of its
strengths.  The future of Emacs is one of the things which has an
impact, and so is the future of GCC.  The GPLv3 is a large "poison pill"
that actually uses copyright in order to disarm the use of patents as a
weapon.  In my opinion, we should rely on its leverage for keeping the
worst of the proprietary misuses in check and give mostly free rein on
interoperability with regard to technical measures.  It's been good
enough for making Apple go away and leave GCC alone for building its
future developer prisons.

For that reason I am glad that John has volunteered to take a look Emacs
maintainership and that he brings the motivation and skills to work on
Emacs being a good IDE and hopefully the motivation to work out with GCC
and RMS about what would be required and how to get there.

Because we've made use of the "it's all talk" excuse far too long for
postponing tackling the increasing issue of interoperability as a design
criterion for Free Software under the GNU umbrella of the FSF.

It's not "all talk" with John on board and I'm glad that he is willing
to talk his application through with Richard.  I severely doubt that it
will be the only time he'll need to talk over things with Richard.

And they are coming at Emacs from different sides and views that will
never be the same and don't need to be.  But the current incompatibility
seems gratuitously bad to me and I think progress on that is quite
necessary.

-- 
David Kastrup