Re: A guide on setting up C/C++ development environment for Emacs

[solidius4747]

> 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 built 
LLVM followed the official guide: http://clang.llvm.org/get_started.html, it 
took me hours with a core i5 machine.

I already updated the guide for people to try Clang solution first, as it seems 
to be more accepted for editor without a built-in language parser. I also 
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++ features. But 
if you see my demo screenshot, you see that CEDET works fine for code 
completion with BOOST. It responded instantly and gave candidates with full 
information (types, parameters and parameter types). I also explicitly 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 IDE. As I 
demoed, it did A GOOD JOB for reasonably sized source tree, like BOOST. 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 parsing.

I use it in my daily job, and it works pretty nice. The current support 
development with C/C++ are much nicer with community packages contributed. When 
I first used Emacs, not Clang solution existed yet. CEDET was the only usable 
solution.

Why CEDET is slow? Because you don't try to do computational expensive tasks 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 least has 
FFI.

Vào 19:27:44 UTC+7 Thứ năm, ngày 28 tháng tám năm 2014, Jai Dayal đã viết:
> > In my experience the
> 
> scientific types are more bigoted than the religious ones.
> 
> 
> 
> Okay, how many people have been killed in the name of science vs. killed in
> 
> the name of religion?
> 
> 
> 
> 
> 
> On Thu, Aug 28, 2014 at 1:39 AM, Rusi <rustompmody@gmail.com> wrote:
> 
> 
> 
> > On Thursday, August 28, 2014 9:59:32 AM UTC+5:30, Óscar Fuentes wrote:
> 
> > > Rusi writes:
> 
> >
> 
> > > [snip]
> 
> >
> 
> > > > Personally I often find FLOSS folks at least as dishonest as the
> 
> > corporate types
> 
> > > > [No surprise, given that human beings are the same...]
> 
> >
> 
> > On second thought I'd tone that down - "at least as dishonest" to "just as
> 
> > dishonest"
> 
> > And then it directly and trivially follows from "human beings are human
> 
> > beings"
> 
> >
> 
> > > Completely agree. The cause of the dishonesty varies, through. The FLOSS
> 
> > > folks tend to think "what is good for me must be good for everybody
> 
> > > else, and those who think different are idiots." Also, they put more
> 
> > > value on following group thinking than on doing cold assessments, even
> 
> > > on those matters that can be assesed on objective terms. BTW, this is
> 
> > > characteristic of religious behavior (or religious behavior is just
> 
> > > another expression of those attitudes.)
> 
> >
> 
> > Sorry I cant let that pass without a protest!  In my experience the
> 
> > scientific types are more bigoted than the religious ones.  As an
> 
> > antidote to bigotry - which is probably what you mean by 'religious
> 
> > behavior' - I recommend the following words of Nagarjuna:
> 
> >
> 
> > | Everything is real and is not real,
> 
> > | Both real and not real,
> 
> > | Neither real nor not real.
> 
> > | This is Lord Buddha's teaching.
> 
> >
> 
> > About group-think: Yes its not nice. But oftentimes very necessary.
> 
> > Here is something I wrote on the python-list just yesterday about why
> 
> > one should choose git over other VCSes.
> 
> >
> 
> > | In modern society we are part users, part masters.  It may be 99% user
> 
> > | 1% master if one is super-intelligent versatile etc -- renaissance men.
> 
> > |
> 
> > | For us more ordinary folk it is more like 99.99% vs 0.01%
> 
> > | Eg I dont know how to repair the car I drive, build the roads they run
> 
> > on,
> 
> > | a frigging clue about the internals of the utilities
> 
> > (electricity/water...)
> 
> > | I consume etc.  Heck this is even true of computers -- the SMPS? the
> 
> > Disk?
> 
> > |
> 
> > | Likewise versioning systems.
> 
> > | We need to use them. We dont need to master all the details
> 
> > | and possibilities.
> 
> > |
> 
> > | Git has won the battle -- maybe because of the mystique around the
> 
> > | name 'Torvalds', maybe for sound technical reasons. It doesn't matter.
> 
> > | If you have better things in your life than becoming a phd in versioning,
> 
> > | I'd say flow with the tide and switch to git
> 
> >