From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: solidius4747@gmail.com Newsgroups: gmane.emacs.help Subject: Re: A guide on setting up C/C++ development environment for Emacs Date: Thu, 28 Aug 2014 08:53:34 -0700 (PDT) Message-ID: <47129814-f079-4441-be39-9387912bca3a@googlegroups.com> References: <513ad0e2-f7f4-484c-b17b-7c94a8c2fc7a@googlegroups.com> <8738chaieo.fsf@wanadoo.es> <87tx4x9353.fsf@wanadoo.es> <87ppfl91ft.fsf@wanadoo.es> <87lhq98zoy.fsf@wanadoo.es> <87ha0x8xbh.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1409241326 19401 80.91.229.3 (28 Aug 2014 15:55:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2014 15:55:26 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 28 17:55:21 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1XN22j-0006LN-Ex for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Aug 2014 17:55:21 +0200 Original-Received: from localhost ([::1]:37696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XN22j-0001QZ-2B for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Aug 2014 11:55:21 -0400 X-Received: by 10.50.80.111 with SMTP id q15mr3190102igx.0.1409241215005; Thu, 28 Aug 2014 08:53:35 -0700 (PDT) X-Received: by 10.50.66.135 with SMTP id f7mr139944igt.3.1409241214840; Thu, 28 Aug 2014 08:53:34 -0700 (PDT) Original-Path: usenet.stanford.edu!uq10no6344758igb.0!news-out.google.com!aw9ni7315igc.0!nntp.google.com!uq10no6344753igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=14.161.13.65; posting-account=c2AWuQoAAACA36o69JJJEmXY5MOg4YNp Original-NNTP-Posting-Host: 14.161.13.65 User-Agent: G2/1.0 Injection-Date: Thu, 28 Aug 2014 15:53:34 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:207198 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:99475 Archived-At: > That's a problem of clang-ctags being slow, not Clang being *so* slow, > because Clang can compile its own sources on a fraction of time of those > 98 minutes (15 minutes here on a 6 year old 4core machine, for an > optimized build.) Are you sure that it took you 15 minutes to build? I'm pretty sure when I b= uilt LLVM followed the official guide: http://clang.llvm.org/get_started.ht= ml, it took me hours with a core i5 machine. I already updated the guide for people to try Clang solution first, as it s= eems to be more accepted for editor without a built-in language parser. I a= lso emphasized in CEDET section that it might be slow for large source tree= like Linux kernel or might not fully up to date to support all the C++ fea= tures. But if you see my demo screenshot, you see that CEDET works fine for= code completion with BOOST. It responded instantly and gave candidates wit= h full information (types, parameters and parameter types). I also explicit= ly wrote the section as: "Source code completion with C++", that means you = only use CEDET for CODE COMPLETION - and no other fancy features in other I= DE. As I demoed, it did A GOOD JOB for reasonably sized source tree, like B= OOST. Here are the two demo screenshots, I post it here again: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif http://tuhdo.github.io/static/auto_complete.gif CEDET also provides a nice tool that is Semantic Symref: http://tuhdo.github.io/static/c-ide/semantic-symref.gif CEDET works best when you start a project from scratch. It will parse your = source tree as you grow it, so there should be almost no waiting for parsin= g. I use it in my daily job, and it works pretty nice. The current support dev= elopment with C/C++ are much nicer with community packages contributed. Whe= n I first used Emacs, not Clang solution existed yet. CEDET was the only us= able solution. Why CEDET is slow? Because you don't try to do computational expensive task= s in Emacs. That's why you delegate heavy works to external processes. But = Emacs could have more possibilities if it can generate native code, or at l= east has FFI. V=C3=A0o 19:27:44 UTC+7 Th=E1=BB=A9 n=C4=83m, ng=C3=A0y 28 th=C3=A1ng t=C3= =A1m n=C4=83m 2014, Jai Dayal =C4=91=C3=A3 vi=E1=BA=BFt: > > In my experience the >=20 > scientific types are more bigoted than the religious ones. >=20 >=20 >=20 > Okay, how many people have been killed in the name of science vs. killed = in >=20 > the name of religion? >=20 >=20 >=20 >=20 >=20 > On Thu, Aug 28, 2014 at 1:39 AM, Rusi wrote: >=20 >=20 >=20 > > On Thursday, August 28, 2014 9:59:32 AM UTC+5:30, =C3=93scar Fuentes wr= ote: >=20 > > > Rusi writes: >=20 > > >=20 > > > [snip] >=20 > > >=20 > > > > Personally I often find FLOSS folks at least as dishonest as the >=20 > > corporate types >=20 > > > > [No surprise, given that human beings are the same...] >=20 > > >=20 > > On second thought I'd tone that down - "at least as dishonest" to "just= as >=20 > > dishonest" >=20 > > And then it directly and trivially follows from "human beings are human >=20 > > beings" >=20 > > >=20 > > > Completely agree. The cause of the dishonesty varies, through. The FL= OSS >=20 > > > folks tend to think "what is good for me must be good for everybody >=20 > > > else, and those who think different are idiots." Also, they put more >=20 > > > value on following group thinking than on doing cold assessments, eve= n >=20 > > > on those matters that can be assesed on objective terms. BTW, this is >=20 > > > characteristic of religious behavior (or religious behavior is just >=20 > > > another expression of those attitudes.) >=20 > > >=20 > > Sorry I cant let that pass without a protest! In my experience the >=20 > > scientific types are more bigoted than the religious ones. As an >=20 > > antidote to bigotry - which is probably what you mean by 'religious >=20 > > behavior' - I recommend the following words of Nagarjuna: >=20 > > >=20 > > | Everything is real and is not real, >=20 > > | Both real and not real, >=20 > > | Neither real nor not real. >=20 > > | This is Lord Buddha's teaching. >=20 > > >=20 > > About group-think: Yes its not nice. But oftentimes very necessary. >=20 > > Here is something I wrote on the python-list just yesterday about why >=20 > > one should choose git over other VCSes. >=20 > > >=20 > > | In modern society we are part users, part masters. It may be 99% use= r >=20 > > | 1% master if one is super-intelligent versatile etc -- renaissance me= n. >=20 > > | >=20 > > | For us more ordinary folk it is more like 99.99% vs 0.01% >=20 > > | Eg I dont know how to repair the car I drive, build the roads they ru= n >=20 > > on, >=20 > > | a frigging clue about the internals of the utilities >=20 > > (electricity/water...) >=20 > > | I consume etc. Heck this is even true of computers -- the SMPS? the >=20 > > Disk? >=20 > > | >=20 > > | Likewise versioning systems. >=20 > > | We need to use them. We dont need to master all the details >=20 > > | and possibilities. >=20 > > | >=20 > > | Git has won the battle -- maybe because of the mystique around the >=20 > > | name 'Torvalds', maybe for sound technical reasons. It doesn't matter= . >=20 > > | If you have better things in your life than becoming a phd in version= ing, >=20 > > | I'd say flow with the tide and switch to git >=20 > >