From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 04 Mar 2014 22:21:35 +0100 Message-ID: <8738ixacdc.fsf@wanadoo.es> References: <20140219080524.25689b6b@forcix.jorgenschaefer.de> <83k3cr58o2.fsf@gnu.org> <530BAEE5.9040004@online.de> <87ppmatkpe.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgfsxsr.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgf37n4.fsf@fencepost.gnu.org> <87ha7gshu9.fsf@uwakimon.sk.tsukuba.ac.jp> <871tyko9l5.fsf@fencepost.gnu.org> <87eh2ks897.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvn0mk25.fsf@fencepost.gnu.org> <87bnxorlol.fsf@uwakimon.sk.tsukuba.ac.jp> <877g8bmxal.fsf@fencepost.gnu.org> <877g8asfl0.fsf@uwakimon.sk.tsukuba.ac.jp> <8738iyjrl3.fsf@fencepost.gnu.org> <87mwh5ridq.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqg9hn10.fsf@fencepost.gnu.org> <878uspaku2.fsf@wanadoo.es> <87k3c9hflv.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1393968120 16646 80.91.229.3 (4 Mar 2014 21:22:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2014 21:22:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 04 22:22:08 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WKwmr-00074t-U1 for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 22:22:06 +0100 Original-Received: from localhost ([::1]:48623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKwmr-0007Y6-Al for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 16:22:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKwmh-0007Nv-0P for emacs-devel@gnu.org; Tue, 04 Mar 2014 16:22:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKwmb-0002C1-Gr for emacs-devel@gnu.org; Tue, 04 Mar 2014 16:21:54 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:35678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKwmb-0002Bv-A9 for emacs-devel@gnu.org; Tue, 04 Mar 2014 16:21:49 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WKwmZ-0006ot-8F for emacs-devel@gnu.org; Tue, 04 Mar 2014 22:21:47 +0100 Original-Received: from 2.red-83-46-213.dynamicip.rima-tde.net ([83.46.213.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Mar 2014 22:21:47 +0100 Original-Received: from ofv by 2.red-83-46-213.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Mar 2014 22:21:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 68 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 2.red-83-46-213.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:uxOF2/23ky6qawiRrnFWVPHmrQA= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170147 Archived-At: David Kastrup writes: > Óscar Fuentes writes: > >> David Kastrup 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. Exactly. So this is not about Emacs features depending on Clang, but about GCC not having Clang features. Unless you say that "C++ parsing" and "C++ native parsing" are two different features. Emacs is just a sacrificial lamb. >> 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. Smart completion is the tip of the iceberg. If GCC limits itself to providing only smart completion, other features that depend on having access to parsing and semantic information will still be missing from GCC. > 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, with all due respect: I think that people like you and RMS who don't know the issue at all from the user's POV (and even loudly despise C++) have no right for telling anyone that they do not understand the matter at hand. As a lifetime C++ programmer who follows GCC, Emacs and Clang communities since a very long time, it is obvious to me that RMS stance will keep GCC and Emacs back for no gain on any aspect, including user's freedom. It is possible that I'm missing some nuances of your political POV, but you are uninterested on the whole technical landscape and its implications. And please don't say that technical issues are secondary here, because understanding those is fundamental for choosing the correct policy. You are like catholic priests dictating how people should deal with sexuality. See what they achieve.