Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> David Kastrup writes:
>
> A lot of misrepresentations.  Two are important to Emacs:
>
>  > And it is most certainly not an "attack" if Emacs developers are
>  > told that Emacs' C/C++ modes should not be equipped with features
>  > that can only work by using Clang internally, consequently
>  > restricting the supported languages
>
> This was the fifth time in your post you've made the unsupported claim
> that use of Clang involves restricting the languages supported by
> Emacs to those supported by Clang.

Language support implemented by letting Emacs call an external parser.
That's what this thread is about.  If the only external parser that can
be called for this purpose is Clang, the languages and dialects
supported by this feature will be those implemented by Clang.

> Please document people advocating that no other technology than Clang
> should be used to implement "smart completion".

We are not talking "should be used".  We are talking "can currently be
used" for functionality that has apparently already slipped into ELPA.

> Surely Óscar advocates Clang (or other AST-producing front end) as the
> most accurate way to do that, but I didn't see him (or anyone else)
> anywhere say that no other techniques should be allowed.

If it is "the most accurate" way, how is that _not_ promoting the use of
Clang for Emacs functionality.

> 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.

-- 
David Kastrup