Re: Emacs contributions, C and Lisp

[David Kastrup]

Óscar Fuentes <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
> [snip]
>
>>> In any case, Richard's argument nowhere depends on *exclusive* use of
>>> Clang.  He simply doesn't want unique features of Clang supported, no
>>> matter how good Emacs's support for GCC is.
>>
>> Sigh.  I don't know _how_ often I have to repeat this.  The problem is
>> not "supporting features of Clang", the problem is _requiring_ features
>> of Clang for supporting features of Emacs.
>>
>> We don't want Emacs features that _depend_ on Clang.
>
> It's clear that that is not RMS intention. Otherwise, for the specific
> case of C++ smart completion, CEDET could default to its own parser and
> provide Clang as an option.

That would be native-parser supported editing _only_ for Clang, not for
GCC.

> But that's not allowed by RMS. He doesn't want Clang on Emacs unless
> *GCC* provides the same features. Which is an unfair scenario for GCC
> because, contrary to Clang, it wasn't intended to provide those
> features, and past attempts to steer its development towards those
> goals were rejected by the same person who now spurs them to match
> Clang's library-like features :-/

He doesn't spur them to match "library-like features".  At the moment
smart completion is what is involved here specifically.  That's quite
not the same.  Personally I think that the time delay associated with
adding features individually is prohibitively large.

But it's impossible to get things in perspective if everybody insists on
misrepresenting Richard and ascribing absurdities to him.

If you refuse to see the issues that are to be balanced, you can't
complain when your input on choosing the balance is discarded as
worthless.

-- 
David Kastrup