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

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

[Tory S. Anderson]

> Oscar isn't too bright and believes in Jesus. Someone of "faith" can never
> be convinced; faith is idiocy by definition.

I don't follow this community enough to know if this is a joke, but in any case it is in bad taste and offensive. I'm disappointed that what I understood to be a forum of professionals would exhibit this kind of discourse.  

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

[Jai Dayal]

Okay but why can people make claims like "scientists are bigots" and that
sort of thing... i even have someone privately emailing me from here
telling me all this stuff about hitler being an atheist and this and that.




On Fri, Aug 29, 2014 at 10:33 AM, Tory S. Anderson <torys.anderson@gmail.com
> wrote:

> > Oscar isn't too bright and believes in Jesus. Someone of "faith" can
> never
> > be convinced; faith is idiocy by definition.
>
> I don't follow this community enough to know if this is a joke, but in any
> case it is in bad taste and offensive. I'm disappointed that what I
> understood to be a forum of professionals would exhibit this kind of
> discourse.
>

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

[Marcin Borkowski]

Dnia 2014-08-29, o godz. 13:21:12
Jai Dayal <dayalsoap@gmail.com> napisał(a):

> Okay but why can people make claims like "scientists are bigots" and
> that sort of thing... i even have someone privately emailing me from
> here telling me all this stuff about hitler being an atheist and this
> and that.

OK, being the "someone" mentioned above, let me get a few things
straight.

1. AFAIR, no one claimed that "scientists are bigots".  Rusi (who was
probably the first one to use the word "bigot") wrote then:

> In my experience the scientific types are more bigoted than the
> religious ones.

This is something *very* different, especially in view of further
explanations from Rusi.  (An exercise for you: find three important
differences between what you wrote and what Rusi wrote.)  Please don't
fight your straw men in public.

2. Could you please tell me *where* I wrote that Hitler was an
atheist?  I *did* claim that he was not Christian (in the sense of the
definition of the word "Christian" *you* have provided, since -
expecting troubles - I asked you for your definition first), and I
*could* give some facts supporting this claim.  And indeed I wanted to
answer your last (off-list) email in private, but seeing that you seem
to have problems with reading comprehension, I guess that my duty (in
the sense of http://xkcd.com/386/) is over.

And just in case someone quotes that stupid Godwin's law: I was *not*
the first one to mention Hitler or Nazis *by name* in the discussion
(though I was close, I admit). ;-)

3. It is well possible that I have IQ lower than you etc.  But: jumping
from a discussion with a couple of (even) idiots to a general
conclusion like

> Someone of "faith" can
> never be convinced; faith is idiocy by definition.

is completely unjustified from logical point of view. (And in fact, a
few thousand of years of history - including more or less famous
conversions - show that both the claims: "someone of faith can never be
convinced" and "faith is idiocy by definition" are entirely wrong.)  Not
to mention offensiveness, which seems to me completely undeserved.

If you want a rational discussion, do not offend people you are talking
to.  If you just want to have some private war against (any) religion,
the mailing list about (maybe the only) text editor which is sometimes
told to have spawned a religion;), may not be the best place, either.

Best regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

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

[Jai Dayal]

How is it different? One can't be more of X without resulting in being
partially X. One is either a bigot, or they aren't, so yes, he is saying
scientists are bigoted.

Faith is believing that something is true, regardless of what the evidence
clearly spells out. How is that not idiotic?


On Fri, Aug 29, 2014 at 2:11 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl>
wrote:

> Dnia 2014-08-29, o godz. 13:21:12
> Jai Dayal <dayalsoap@gmail.com> napisał(a):
>
> > Okay but why can people make claims like "scientists are bigots" and
> > that sort of thing... i even have someone privately emailing me from
> > here telling me all this stuff about hitler being an atheist and this
> > and that.
>
> OK, being the "someone" mentioned above, let me get a few things
> straight.
>
> 1. AFAIR, no one claimed that "scientists are bigots".  Rusi (who was
> probably the first one to use the word "bigot") wrote then:
>
> > In my experience the scientific types are more bigoted than the
> > religious ones.
>
> This is something *very* different, especially in view of further
> explanations from Rusi.  (An exercise for you: find three important
> differences between what you wrote and what Rusi wrote.)  Please don't
> fight your straw men in public.
>
> 2. Could you please tell me *where* I wrote that Hitler was an
> atheist?  I *did* claim that he was not Christian (in the sense of the
> definition of the word "Christian" *you* have provided, since -
> expecting troubles - I asked you for your definition first), and I
> *could* give some facts supporting this claim.  And indeed I wanted to
> answer your last (off-list) email in private, but seeing that you seem
> to have problems with reading comprehension, I guess that my duty (in
> the sense of http://xkcd.com/386/) is over.
>
> And just in case someone quotes that stupid Godwin's law: I was *not*
> the first one to mention Hitler or Nazis *by name* in the discussion
> (though I was close, I admit). ;-)
>
> 3. It is well possible that I have IQ lower than you etc.  But: jumping
> from a discussion with a couple of (even) idiots to a general
> conclusion like
>
> > Someone of "faith" can
> > never be convinced; faith is idiocy by definition.
>
> is completely unjustified from logical point of view. (And in fact, a
> few thousand of years of history - including more or less famous
> conversions - show that both the claims: "someone of faith can never be
> convinced" and "faith is idiocy by definition" are entirely wrong.)  Not
> to mention offensiveness, which seems to me completely undeserved.
>
> If you want a rational discussion, do not offend people you are talking
> to.  If you just want to have some private war against (any) religion,
> the mailing list about (maybe the only) text editor which is sometimes
> told to have spawned a religion;), may not be the best place, either.
>
> Best regards,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>
>

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

[Marcin Borkowski]

Dnia 2014-08-29, o godz. 14:15:48
Jai Dayal <dayalsoap@gmail.com> napisał(a):

> How is it different? One can't be more of X without resulting in being
> partially X. One is either a bigot, or they aren't, so yes, he is
> saying scientists are bigoted.

Ah!  Now I get it.  You seem to be reasoning in binary categories.
Either you are a bigot or not.  Either something is science or not.
Let me extrapolate a bit: either someone is an idiot or a genius.
Which one are you?  (SCNR...)

And putting irony aside: *if* you claim that if someone is even *a
tiny bit* bigoted, then he can be called a bigot, could you please
tell me who is *not* a bigot?

And here's a solution to your exercise: Rusi also said "in my
experience", which you conveniently omitted from your "quotation", and
also he used the words "scientific types", which is not exactly the
same as "scientists" - as you "quoted" him.

And, you silently ignored my second question.  How convenient.

> Faith is believing that something is true, regardless of what the
> evidence clearly spells out. How is that not idiotic?

I have to admit that it is the first time I see this definition of
"faith", and I wouldn't agree with it.  This closes the discussion (I
hope so at least, I have some work to do, you know).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

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

[Jai Dayal]

Not being a genius does not make you an idiot; however, one either meets
the classification of a genius or one does not. Just because there are
binary memberships for some objects wrt classes, it does not mean all
classifications are binary. Being a bigot, however, is binary.

>And putting irony aside: *if* you claim that if someone is even *a
tiny bit* bigoted, then he can be called a bigot, could you please
tell me who is *not* a bigot?

That's not for me to decide. The statement that was made was that
scientists are *more* bigoted than religious types. How can a scientist be
more bigoted than something without being a bigot? It makes no sense.

>Rusi also said "in my
experience"

I don't see how that's relevant. "In my opinion, you are stupid" isn't
really that functionally different in layman speak to "you are stupid".

>I have to admit that it is the first time I see this definition of
"faith", and I wouldn't agree with it.  This closes the discussion (I
hope so at least, I have some work to do, you know).

It really isn't though. There is a difference between beliefs and
evidenced-based reasoning. Faith is *believing* something to be true 100%
regardless of the evidence.


On Fri, Aug 29, 2014 at 2:27 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl>
wrote:

> Dnia 2014-08-29, o godz. 14:15:48
> Jai Dayal <dayalsoap@gmail.com> napisał(a):
>
> > How is it different? One can't be more of X without resulting in being
> > partially X. One is either a bigot, or they aren't, so yes, he is
> > saying scientists are bigoted.
>
> Ah!  Now I get it.  You seem to be reasoning in binary categories.
> Either you are a bigot or not.  Either something is science or not.
> Let me extrapolate a bit: either someone is an idiot or a genius.
> Which one are you?  (SCNR...)
>
> And putting irony aside: *if* you claim that if someone is even *a
> tiny bit* bigoted, then he can be called a bigot, could you please
> tell me who is *not* a bigot?
>
> And here's a solution to your exercise: Rusi also said "in my
> experience", which you conveniently omitted from your "quotation", and
> also he used the words "scientific types", which is not exactly the
> same as "scientists" - as you "quoted" him.
>
> And, you silently ignored my second question.  How convenient.
>
> > Faith is believing that something is true, regardless of what the
> > evidence clearly spells out. How is that not idiotic?
>
> I have to admit that it is the first time I see this definition of
> "faith", and I wouldn't agree with it.  This closes the discussion (I
> hope so at least, I have some work to do, you know).
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>
>

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

[Marcin Borkowski]

Dnia 2014-08-29, o godz. 14:34:32
Jai Dayal <dayalsoap@gmail.com> napisał(a):

> >Rusi also said "in my experience"
> 
> I don't see how that's relevant. "In my opinion, you are stupid" isn't
> really that functionally different in layman speak to "you are
> stupid".

opinion ≠ experience.

> >I have to admit that it is the first time I see this definition of
> "faith", and I wouldn't agree with it.  This closes the discussion (I
> hope so at least, I have some work to do, you know).
> 
> It really isn't though. There is a difference between beliefs and
> evidenced-based reasoning. Faith is *believing* something to be true
> 100% regardless of the evidence.

Of course there's a difference, and a huge one indeed.  Just as there
is a difference between faith and idiocy.  Also a huge one.

In order to discuss your second claim: (1) agreement on the definition
of "evidence" needed (hard) and (2) agreement on the definition of
"faith" needed (even harder).

Discussion about this = fun, useful.

Discussion about this with someone who misquotes and offends people =
  not fun, less useful.

I'm getting back to my family and my work, bye.

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

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

[Rusi]

On Friday, August 29, 2014 11:41:33 PM UTC+5:30, Marcin Borkowski wrote:
> Dnia 2014-08-29, o godz. 13:21:12
> Jai Dayal napisał(a):

> > Okay but why can people make claims like "scientists are bigots" and
> > that sort of thing... i even have someone privately emailing me from
> > here telling me all this stuff about hitler being an atheist and this
> > and that.

> OK, being the "someone" mentioned above, let me get a few things
> straight.

> 1. AFAIR, no one claimed that "scientists are bigots".  Rusi (who was
> probably the first one to use the word "bigot") wrote then:

> > In my experience the scientific types are more bigoted than the
> > religious ones.

> This is something *very* different, especially in view of further
> explanations from Rusi.  (An exercise for you: find three important
> differences between what you wrote and what Rusi wrote.)  Please don't
> fight your straw men in public.

I was hunting for a quote of Meister Eckhart.
Couldn't find what I wanted but found this which amused me in the context
of this thread

| Truth is something so noble that if God could turn aside from it, I
| could keep the truth and let God go.
from http://en.wikiquote.org/wiki/Meister_Eckhart

So surely Meister Eckhart is very scientific and un-religious <wink>??

Marcin wrote:
> Jai Dayal <daya...@gmail.com> napisał(a):
> 
> > How is it different? One can't be more of X without resulting in being
> > partially X. One is either a bigot, or they aren't, so yes, he is
> > saying scientists are bigoted.

> Ah!  Now I get it.  You seem to be reasoning in binary categories.
> Either you are a bigot or not.  Either something is science or not. 

Yes that sums up what I wanted to say.

I am not specifically pro or anti religion or science.
I am anti binary thinking.

And Aristotle's law (even called the Law of excluded middle):
| Everything is either A or not A.

is the same as a certain Neanderthal, twice-voted head of state's

| Either you are with us or against us

My quote from Nagarjuna was essentially (my) antidote to binary thinking.

Since in sanskrit 'sat' can as much be rendered as 'truth' as 'reality'
here's my re-rendering:

| Everything is true and is not true,
| Both true and not true,
| Neither true nor not true.
| This is <insert favorite esteemable figure>'s teaching. 

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

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]


() Rusi <rustompmody@gmail.com>
() Fri, 29 Aug 2014 20:43:52 -0700 (PDT)

   | This is <insert favorite esteemable figure>'s teaching. 

emacs: incomplete?
circular thread now woven,
one and zero smile.

thi


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Jai Dayal]

It's irrelevant as to whether or not you are "anti-binary" thinking. Binary
classifications exist. It's a reality your "faith" seems to have a
hard-time understanding.

Quoting philosophers and witch doctors also has little to do with reality,
despite assisting in your faith-driven beliefs.


On Fri, Aug 29, 2014 at 11:43 PM, Rusi <rustompmody@gmail.com> wrote:

> On Friday, August 29, 2014 11:41:33 PM UTC+5:30, Marcin Borkowski wrote:
> > Dnia 2014-08-29, o godz. 13:21:12
> > Jai Dayal napisał(a):
>
> > > Okay but why can people make claims like "scientists are bigots" and
> > > that sort of thing... i even have someone privately emailing me from
> > > here telling me all this stuff about hitler being an atheist and this
> > > and that.
>
> > OK, being the "someone" mentioned above, let me get a few things
> > straight.
>
> > 1. AFAIR, no one claimed that "scientists are bigots".  Rusi (who was
> > probably the first one to use the word "bigot") wrote then:
>
> > > In my experience the scientific types are more bigoted than the
> > > religious ones.
>
> > This is something *very* different, especially in view of further
> > explanations from Rusi.  (An exercise for you: find three important
> > differences between what you wrote and what Rusi wrote.)  Please don't
> > fight your straw men in public.
>
> I was hunting for a quote of Meister Eckhart.
> Couldn't find what I wanted but found this which amused me in the context
> of this thread
>
> | Truth is something so noble that if God could turn aside from it, I
> | could keep the truth and let God go.
> from http://en.wikiquote.org/wiki/Meister_Eckhart
>
> So surely Meister Eckhart is very scientific and un-religious <wink>??
>
> Marcin wrote:
> > Jai Dayal <daya...@gmail.com> napisał(a):
> >
> > > How is it different? One can't be more of X without resulting in being
> > > partially X. One is either a bigot, or they aren't, so yes, he is
> > > saying scientists are bigoted.
>
> > Ah!  Now I get it.  You seem to be reasoning in binary categories.
> > Either you are a bigot or not.  Either something is science or not.
>
> Yes that sums up what I wanted to say.
>
> I am not specifically pro or anti religion or science.
> I am anti binary thinking.
>
> And Aristotle's law (even called the Law of excluded middle):
> | Everything is either A or not A.
>
> is the same as a certain Neanderthal, twice-voted head of state's
>
> | Either you are with us or against us
>
> My quote from Nagarjuna was essentially (my) antidote to binary thinking.
>
> Since in sanskrit 'sat' can as much be rendered as 'truth' as 'reality'
> here's my re-rendering:
>
> | Everything is true and is not true,
> | Both true and not true,
> | Neither true nor not true.
> | This is <insert favorite esteemable figure>'s teaching.
>

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

[Rusi]

On Sunday, August 31, 2014 2:57:18 AM UTC+5:30, Jai Dayal wrote:
> It's irrelevant as to whether or not you are "anti-binary" thinking. Binary
> classifications exist. It's a reality your "faith" seems to have a
> hard-time understanding.

> Quoting philosophers and witch doctors also has little to do with reality,
> despite assisting in your faith-driven beliefs.

Good luck to you. And God bless!
[And dont top-post]

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

[solidius4747]

Hi list,

I wrote a guide on setting up C/C++ development in Emacs that covers the following topics:

- Source code navigation: jump around Linux kernel with easy, find any file in project, find any definition and reference in project.
- Smart completion with CEDET and Semantic.
- More code navigation with Senator.
- Project management with EDE and Projectile.
- Display source code source code information with semantic-idle-summary-mode and semantic-sticky-func-mode. semantic-idle-summary-mode displays function interface in the minibuffer and semantic-sticky-func-mode displays interface of current function point is in.
- Utilities for source code editing.
- Compile with Compilation mode.
- Debugging with GDB Many Windows or plain old GUD.

The link: http://tuhdo.github.io/c-ide.html

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

[Dmitriy Igrishin]

Hi,

Amazing work. Thank you!

Although, I don't use CEDET because it's terrible slow for me.


2014-08-27 11:05 GMT+04:00 <solidius4747@gmail.com>:

> Hi list,
>
> I wrote a guide on setting up C/C++ development in Emacs that covers the
> following topics:
>
> - Source code navigation: jump around Linux kernel with easy, find any
> file in project, find any definition and reference in project.
> - Smart completion with CEDET and Semantic.
> - More code navigation with Senator.
> - Project management with EDE and Projectile.
> - Display source code source code information with
> semantic-idle-summary-mode and semantic-sticky-func-mode.
> semantic-idle-summary-mode displays function interface in the minibuffer
> and semantic-sticky-func-mode displays interface of current function point
> is in.
> - Utilities for source code editing.
> - Compile with Compilation mode.
> - Debugging with GDB Many Windows or plain old GUD.
>
> The link: http://tuhdo.github.io/c-ide.html
>



-- 
// Dmitriy.

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

[Tu Hoang Do]

CEDET is not slow. It's reasonably fast given it is implemented in Emacs
Lisp. It needs time for parsing to build a database, so you see a message
printing this: parsing....<file> in the minibuffer. It needs parsing to
build up a database for smart completion. After the first time parsing,
completion happens instantly and you should enable Semanticdb minor mode to
save the parsing results, so CEDET won't have to parse the next time. CEDET
can handle project with the size of Emacs really well. I think even project
with more than a million lines of code. CEDET is the only viable solution
so far I found for real smart completion in Emacs. Other clang based
solution is pretty limited: you can only get completion from system header
and current directory, but not for your project. You have to add the
include paths to tell Clang where your project include paths are, and you
have to specify with absolute paths. It's really tedious.


On Wed, Aug 27, 2014 at 7:48 PM, Dmitriy Igrishin <dmitigr@gmail.com> wrote:

> Hi,
>
> Amazing work. Thank you!
>
> Although, I don't use CEDET because it's terrible slow for me.
>
>
> 2014-08-27 11:05 GMT+04:00 <solidius4747@gmail.com>:
>
>> Hi list,
>>
>> I wrote a guide on setting up C/C++ development in Emacs that covers the
>> following topics:
>>
>> - Source code navigation: jump around Linux kernel with easy, find any
>> file in project, find any definition and reference in project.
>> - Smart completion with CEDET and Semantic.
>> - More code navigation with Senator.
>> - Project management with EDE and Projectile.
>> - Display source code source code information with
>> semantic-idle-summary-mode and semantic-sticky-func-mode.
>> semantic-idle-summary-mode displays function interface in the minibuffer
>> and semantic-sticky-func-mode displays interface of current function point
>> is in.
>> - Utilities for source code editing.
>> - Compile with Compilation mode.
>> - Debugging with GDB Many Windows or plain old GUD.
>>
>> The link: http://tuhdo.github.io/c-ide.html
>>
>
>
>
> --
> // Dmitriy.
>
>

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

[Dmitriy Igrishin]

2014-08-27 17:18 GMT+04:00 Tu Hoang Do <solidius4747@gmail.com>:

> CEDET is not slow. It's reasonably fast given it is implemented in Emacs
> Lisp. It needs time for parsing to build a database, so you see a message
> printing this: parsing....<file> in the minibuffer. It needs parsing to
> build up a database for smart completion. After the first time parsing,
> completion happens instantly and you should enable Semanticdb minor mode to
> save the parsing results, so CEDET won't have to parse the next time. CEDET
> can handle project with the size of Emacs really well. I think even project
> with more than a million lines of code. CEDET is the only viable solution
> so far I found for real smart completion in Emacs. Other clang based
> solution is pretty limited: you can only get completion from system header
> and current directory, but not for your project. You have to add the
> include paths to tell Clang where your project include paths are, and you
> have to specify with absolute paths. It's really tedious.
>
No, it does not real smart. For example, please, try to
M-x semantic-ia-complete-symbol-menu
when you are in method implementation like this:
void Class::method()
{
  // M-x semantic-ia-complete-symbol-menu should show a menu
  // with all members in the scope. But nothing is shown.
}
Second example. Please, try to M-x semantic-ia-complete-symbol-menu
when you are in
void Class::method()
{
  method2(
  // M-x semantic-ia-complete-symbol-menu after the "(" will
  // freeze Emacs to do some of stupid thinking.
  // Terrible, horrible and sad. And nothing more.
}

After this, I don't want to use CEDET without any sorry.
Sorry.

-- 
// Dmitriy.

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

[Tu Hoang Do]

For C, CEDET works really well. For C++, it is a quite incomplete but
usable.  I already showed the smart completion in this screenshot:
http://tuhdo.github.io/static/auto_complete.gif

Notice in the screenshot before and after I include linux/printk.h  CEDET
realizes the change in buffer and adapt immediately. But, as I said, you
need to leave it sometimes for parsing the first time you perform smart
completion from included files. Here is another example with using CEDET
with Boost: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif

CEDET actually understands your source code by trying to parse properly. It
works mostly with C.

please, try to M-x semantic-ia-complete-
> symbol-menu
> when you are in method implementation like this:
> void Class::method()
> {
>   // M-x semantic-ia-complete-symbol-menu should show a menu
>   // with all members in the scope. But nothing is shown.
>
}
>

For this use case, I agree this is a limitation. You need to have a prefix
for it to start completion. I think this should be less of a problem since
if you have many include files, you have a huge pool of completion
candidates that you have to narrow down anyway.


Second example. Please, try to M-x semantic-ia-complete-symbol-menu
> when you are in
> void Class::method()
> {
>   method2(
>   // M-x semantic-ia-complete-symbol-menu after the "(" will
>   // freeze Emacs to do some of stupid thinking.
>   // Terrible, horrible and sad. And nothing more.
> }
>

Parsing is an intensive task. To make CEDET work well, *you have to wait*
for it to biuld up the database for future use. For an implementation in
Pure Elisp, it is quite fast for reasonable size projects and is cross
platform. Getting Clang to work on Windows is not easy. Also, it is the
limitation of single threaded Emacs. To provides real IDE features like in
other IDEs, Emacs needs must be able to do many things at once, like
analyzing and checking. Since Emacs is single threaded, anything heavy
weight blocks it. You have to wait for a few minutes if you only include
like ten header files and your project is not too large. The way it works
is like this: for each included file, it parse the that file and if the
included file includes further files it will move deeply into those files
and parse until reaching the end.* Subsequent parsing results in less
time *because
CEDET can make use of previous parsing result. I heard that in the future
Emacs will come with cooperative threads, and it makes tasks like parsing
and syntax checking can coexist with editing.

After this, I don't want to use CEDET without any sorry.
> Sorry.
>

Sure. You always have alternatives such as other Clang solutions. But it
won't be complete either. It can complete candidates in system header files
fine, but if you want to complete for project wise, you have to give it
include paths written in absolute path.

Or, you can just use GNU Global with Emacs frontend that provides a not so
accurate for C++ but practical solution. It's really fast. I can walk the
Linux kernel with ease. You can use company-gtags to get a list of all
possible completions in your project.

Thanks.

On Wed, Aug 27, 2014 at 9:15 PM, Dmitriy Igrishin <dmitigr@gmail.com> wrote:

>
>
>
> 2014-08-27 17:18 GMT+04:00 Tu Hoang Do <solidius4747@gmail.com>:
>
> CEDET is not slow. It's reasonably fast given it is implemented in Emacs
>> Lisp. It needs time for parsing to build a database, so you see a message
>> printing this: parsing....<file> in the minibuffer. It needs parsing to
>> build up a database for smart completion. After the first time parsing,
>> completion happens instantly and you should enable Semanticdb minor mode to
>> save the parsing results, so CEDET won't have to parse the next time. CEDET
>> can handle project with the size of Emacs really well. I think even project
>> with more than a million lines of code. CEDET is the only viable solution
>> so far I found for real smart completion in Emacs. Other clang based
>> solution is pretty limited: you can only get completion from system header
>> and current directory, but not for your project. You have to add the
>> include paths to tell Clang where your project include paths are, and you
>> have to specify with absolute paths. It's really tedious.
>>
> No, it does not real smart. For example, please, try to
> M-x semantic-ia-complete-symbol-menu
> when you are in method implementation like this:
> void Class::method()
> {
>   // M-x semantic-ia-complete-symbol-menu should show a menu
>   // with all members in the scope. But nothing is shown.
> }
> Second example. Please, try to M-x semantic-ia-complete-symbol-menu
> when you are in
> void Class::method()
> {
>   method2(
>   // M-x semantic-ia-complete-symbol-menu after the "(" will
>   // freeze Emacs to do some of stupid thinking.
>   // Terrible, horrible and sad. And nothing more.
> }
>
> After this, I don't want to use CEDET without any sorry.
> Sorry.
>
> --
> // Dmitriy.
>
>

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

[Tu Hoang Do]

>
>  Yes, and it seems to me like a reason to not use C++. Really.
> It's has so horrible syntax/grammar (compared e.g. to Lisp),
> so in 2014 there is no complete solution to work with comfort.
> Seriosly, there is a SLIME, there is a CEDET (which works well only
> with C), but there is no complete support for C++ around. Only a
> set of workarounds and disappointments.
>

Sure, so do I. I took a C job and my C++ is fading away. Probably I only
use C++ as C with classes and templates. For C++, at least Clang can work
with it and I've just added a section on how to use company-clang and
.dir-locals.el to provide project completion:
http://tuhdo.github.io/c-ide.html#sec-2


Yes, I understood about CEDET parsing infrastructure. But the case above
> is about a CEDET bug, rather than caching
>

Probably. I haven't encountered the problem. For your first CEDET problem,
you can use company-semantic and it will give you completion, even without
anay prefix.

Or I can just use Qt Creator or just abandon the C++ and do my high-level
>
abstractions and programming in Lisp, and low-level programming in C.
>

That works fine. I prefer the later.

On Reddit I had a discussion with another user about IDE like QtCreator vs
Emacs:
http://www.reddit.com/r/cpp/comments/2efh2c/cc_development_environment_for_emacs/cjz03qr

I can understand the value QtCreator provides, but when I need to work with
a project with multiple languages (i.e. not only your language source
files, you also have bash scripts, Makefile, test written in other
languages, submodules in other languages...) then Emacs will be better in
general operations. In general, QtCreator provides better C++ support than
most IDEs and editors, include Eclipse.



On Wed, Aug 27, 2014 at 11:21 PM, Dmitriy Igrishin <dmitigr@gmail.com>
wrote:

>
>
>
> 2014-08-27 18:53 GMT+04:00 Tu Hoang Do <solidius4747@gmail.com>:
>
> For C, CEDET works really well. For C++, it is a quite incomplete but
>> usable.  I already showed the smart completion in this screenshot:
>> http://tuhdo.github.io/static/auto_complete.gif
>>
>
>>
>> Notice in the screenshot before and after I include linux/printk.h  CEDET
>> realizes the change in buffer and adapt immediately. But, as I said, you
>> need to leave it sometimes for parsing the first time you perform smart
>> completion from included files. Here is another example with using CEDET
>> with Boost: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif
>>
>> CEDET actually understands your source code by trying to parse properly.
>> It
>> works mostly with C.
>>
> Yes, and it seems to me like a reason to not use C++. Really.
> It's has so horrible syntax/grammar (compared e.g. to Lisp),
> so in 2014 there is no complete solution to work with comfort.
> Seriosly, there is a SLIME, there is a CEDET (which works well only
> with C), but there is no complete support for C++ around. Only a
> set of workarounds and disappointments.
>
>>
>
>>
>> please, try to M-x semantic-ia-complete-
>> > symbol-menu
>> > when you are in method implementation like this:
>> > void Class::method()
>> > {
>> >   // M-x semantic-ia-complete-symbol-menu should show a menu
>> >   // with all members in the scope. But nothing is shown.
>> >
>> }
>> >
>>
>> For this use case, I agree this is a limitation. You need to have a prefix
>> for it to start completion. I think this should be less of a problem since
>> if you have many include files, you have a huge pool of completion
>> candidates that you have to narrow down anyway.
>>
>>
>> Second example. Please, try to M-x semantic-ia-complete-symbol-menu
>> > when you are in
>> > void Class::method()
>> > {
>> >   method2(
>> >   // M-x semantic-ia-complete-symbol-menu after the "(" will
>> >   // freeze Emacs to do some of stupid thinking.
>> >   // Terrible, horrible and sad. And nothing more.
>> > }
>> >
>>
>> Parsing is an intensive task. To make CEDET work well, *you have to wait*
>>
>> for it to biuld up the database for future use. For an implementation in
>> Pure Elisp, it is quite fast for reasonable size projects and is cross
>> platform. Getting Clang to work on Windows is not easy. Also, it is the
>> limitation of single threaded Emacs. To provides real IDE features like in
>> other IDEs, Emacs needs must be able to do many things at once, like
>> analyzing and checking. Since Emacs is single threaded, anything heavy
>> weight blocks it. You have to wait for a few minutes if you only include
>> like ten header files and your project is not too large. The way it works
>> is like this: for each included file, it parse the that file and if the
>> included file includes further files it will move deeply into those files
>> and parse until reaching the end.* Subsequent parsing results in less
>> time *because
>>
>> CEDET can make use of previous parsing result. I heard that in the future
>> Emacs will come with cooperative threads, and it makes tasks like parsing
>> and syntax checking can coexist with editing.
>>
> Yes, I understood about CEDET parsing infrastructure. But the case above
> is about a CEDET bug, rather than caching. You may call
> M-x semantic-ia-complete-symbol-menu after the "(" in the case above many
> times and Emacs will be freezed many times accordingly.
>
>>
>> After this, I don't want to use CEDET without any sorry.
>> > Sorry.
>> >
>>
>> Sure. You always have alternatives such as other Clang solutions. But it
>> won't be complete either. It can complete candidates in system header
>> files
>> fine, but if you want to complete for project wise, you have to give it
>> include paths written in absolute path.
>>
>> Or, you can just use GNU Global with Emacs frontend that provides a not so
>> accurate for C++ but practical solution. It's really fast. I can walk the
>> Linux kernel with ease. You can use company-gtags to get a list of all
>> possible completions in your project.
>>
> Or I can just use Qt Creator or just abandon the C++ and do my high-level
> abstractions and programming in Lisp, and low-level programming in C.
>
>>
>> Thanks.
>>
>> On Wed, Aug 27, 2014 at 9:15 PM, Dmitriy Igrishin <dmitigr@gmail.com>
>> wrote:
>>
>> >
>> >
>> >
>> > 2014-08-27 17:18 GMT+04:00 Tu Hoang Do <solidius4747@gmail.com>:
>> >
>> > CEDET is not slow. It's reasonably fast given it is implemented in Emacs
>> >> Lisp. It needs time for parsing to build a database, so you see a
>> message
>> >> printing this: parsing....<file> in the minibuffer. It needs parsing to
>> >> build up a database for smart completion. After the first time parsing,
>> >> completion happens instantly and you should enable Semanticdb minor
>> mode to
>> >> save the parsing results, so CEDET won't have to parse the next time.
>> CEDET
>> >> can handle project with the size of Emacs really well. I think even
>> project
>> >> with more than a million lines of code. CEDET is the only viable
>> solution
>> >> so far I found for real smart completion in Emacs. Other clang based
>> >> solution is pretty limited: you can only get completion from system
>> header
>> >> and current directory, but not for your project. You have to add the
>> >> include paths to tell Clang where your project include paths are, and
>> you
>> >> have to specify with absolute paths. It's really tedious.
>> >>
>> > No, it does not real smart. For example, please, try to
>> > M-x semantic-ia-complete-symbol-menu
>> > when you are in method implementation like this:
>> > void Class::method()
>> > {
>> >   // M-x semantic-ia-complete-symbol-menu should show a menu
>> >   // with all members in the scope. But nothing is shown.
>> > }
>> > Second example. Please, try to M-x semantic-ia-complete-symbol-menu
>> > when you are in
>> > void Class::method()
>> > {
>> >   method2(
>> >   // M-x semantic-ia-complete-symbol-menu after the "(" will
>> >   // freeze Emacs to do some of stupid thinking.
>> >   // Terrible, horrible and sad. And nothing more.
>> > }
>> >
>> > After this, I don't want to use CEDET without any sorry.
>> > Sorry.
>> >
>> > --
>> > // Dmitriy.
>> >
>> >
>>
>
>
>
> --
> // Dmitriy.
>
>

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

[Jai Dayal]

Any mention of CEDET always turns into this kind of discussion.


On Wed, Aug 27, 2014 at 2:14 PM, Tu Hoang Do <solidius4747@gmail.com> wrote:

> >
> >  Yes, and it seems to me like a reason to not use C++. Really.
> > It's has so horrible syntax/grammar (compared e.g. to Lisp),
> > so in 2014 there is no complete solution to work with comfort.
> > Seriosly, there is a SLIME, there is a CEDET (which works well only
> > with C), but there is no complete support for C++ around. Only a
> > set of workarounds and disappointments.
> >
>
> Sure, so do I. I took a C job and my C++ is fading away. Probably I only
> use C++ as C with classes and templates. For C++, at least Clang can work
> with it and I've just added a section on how to use company-clang and
> .dir-locals.el to provide project completion:
> http://tuhdo.github.io/c-ide.html#sec-2
>
>
> Yes, I understood about CEDET parsing infrastructure. But the case above
> > is about a CEDET bug, rather than caching
> >
>
> Probably. I haven't encountered the problem. For your first CEDET problem,
> you can use company-semantic and it will give you completion, even without
> anay prefix.
>
> Or I can just use Qt Creator or just abandon the C++ and do my high-level
> >
> abstractions and programming in Lisp, and low-level programming in C.
> >
>
> That works fine. I prefer the later.
>
> On Reddit I had a discussion with another user about IDE like QtCreator vs
> Emacs:
>
> http://www.reddit.com/r/cpp/comments/2efh2c/cc_development_environment_for_emacs/cjz03qr
>
> I can understand the value QtCreator provides, but when I need to work with
> a project with multiple languages (i.e. not only your language source
> files, you also have bash scripts, Makefile, test written in other
> languages, submodules in other languages...) then Emacs will be better in
> general operations. In general, QtCreator provides better C++ support than
> most IDEs and editors, include Eclipse.
>
>
>
> On Wed, Aug 27, 2014 at 11:21 PM, Dmitriy Igrishin <dmitigr@gmail.com>
> wrote:
>
> >
> >
> >
> > 2014-08-27 18:53 GMT+04:00 Tu Hoang Do <solidius4747@gmail.com>:
> >
> > For C, CEDET works really well. For C++, it is a quite incomplete but
> >> usable.  I already showed the smart completion in this screenshot:
> >> http://tuhdo.github.io/static/auto_complete.gif
> >>
> >
> >>
> >> Notice in the screenshot before and after I include linux/printk.h
> CEDET
> >> realizes the change in buffer and adapt immediately. But, as I said, you
> >> need to leave it sometimes for parsing the first time you perform smart
> >> completion from included files. Here is another example with using CEDET
> >> with Boost: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif
> >>
> >> CEDET actually understands your source code by trying to parse properly.
> >> It
> >> works mostly with C.
> >>
> > Yes, and it seems to me like a reason to not use C++. Really.
> > It's has so horrible syntax/grammar (compared e.g. to Lisp),
> > so in 2014 there is no complete solution to work with comfort.
> > Seriosly, there is a SLIME, there is a CEDET (which works well only
> > with C), but there is no complete support for C++ around. Only a
> > set of workarounds and disappointments.
> >
> >>
> >
> >>
> >> please, try to M-x semantic-ia-complete-
> >> > symbol-menu
> >> > when you are in method implementation like this:
> >> > void Class::method()
> >> > {
> >> >   // M-x semantic-ia-complete-symbol-menu should show a menu
> >> >   // with all members in the scope. But nothing is shown.
> >> >
> >> }
> >> >
> >>
> >> For this use case, I agree this is a limitation. You need to have a
> prefix
> >> for it to start completion. I think this should be less of a problem
> since
> >> if you have many include files, you have a huge pool of completion
> >> candidates that you have to narrow down anyway.
> >>
> >>
> >> Second example. Please, try to M-x semantic-ia-complete-symbol-menu
> >> > when you are in
> >> > void Class::method()
> >> > {
> >> >   method2(
> >> >   // M-x semantic-ia-complete-symbol-menu after the "(" will
> >> >   // freeze Emacs to do some of stupid thinking.
> >> >   // Terrible, horrible and sad. And nothing more.
> >> > }
> >> >
> >>
> >> Parsing is an intensive task. To make CEDET work well, *you have to
> wait*
> >>
> >> for it to biuld up the database for future use. For an implementation in
> >> Pure Elisp, it is quite fast for reasonable size projects and is cross
> >> platform. Getting Clang to work on Windows is not easy. Also, it is the
> >> limitation of single threaded Emacs. To provides real IDE features like
> in
> >> other IDEs, Emacs needs must be able to do many things at once, like
> >> analyzing and checking. Since Emacs is single threaded, anything heavy
> >> weight blocks it. You have to wait for a few minutes if you only include
> >> like ten header files and your project is not too large. The way it
> works
> >> is like this: for each included file, it parse the that file and if the
> >> included file includes further files it will move deeply into those
> files
> >> and parse until reaching the end.* Subsequent parsing results in less
> >> time *because
> >>
> >> CEDET can make use of previous parsing result. I heard that in the
> future
> >> Emacs will come with cooperative threads, and it makes tasks like
> parsing
> >> and syntax checking can coexist with editing.
> >>
> > Yes, I understood about CEDET parsing infrastructure. But the case above
> > is about a CEDET bug, rather than caching. You may call
> > M-x semantic-ia-complete-symbol-menu after the "(" in the case above many
> > times and Emacs will be freezed many times accordingly.
> >
> >>
> >> After this, I don't want to use CEDET without any sorry.
> >> > Sorry.
> >> >
> >>
> >> Sure. You always have alternatives such as other Clang solutions. But it
> >> won't be complete either. It can complete candidates in system header
> >> files
> >> fine, but if you want to complete for project wise, you have to give it
> >> include paths written in absolute path.
> >>
> >> Or, you can just use GNU Global with Emacs frontend that provides a not
> so
> >> accurate for C++ but practical solution. It's really fast. I can walk
> the
> >> Linux kernel with ease. You can use company-gtags to get a list of all
> >> possible completions in your project.
> >>
> > Or I can just use Qt Creator or just abandon the C++ and do my high-level
> > abstractions and programming in Lisp, and low-level programming in C.
> >
> >>
> >> Thanks.
> >>
> >> On Wed, Aug 27, 2014 at 9:15 PM, Dmitriy Igrishin <dmitigr@gmail.com>
> >> wrote:
> >>
> >> >
> >> >
> >> >
> >> > 2014-08-27 17:18 GMT+04:00 Tu Hoang Do <solidius4747@gmail.com>:
> >> >
> >> > CEDET is not slow. It's reasonably fast given it is implemented in
> Emacs
> >> >> Lisp. It needs time for parsing to build a database, so you see a
> >> message
> >> >> printing this: parsing....<file> in the minibuffer. It needs parsing
> to
> >> >> build up a database for smart completion. After the first time
> parsing,
> >> >> completion happens instantly and you should enable Semanticdb minor
> >> mode to
> >> >> save the parsing results, so CEDET won't have to parse the next time.
> >> CEDET
> >> >> can handle project with the size of Emacs really well. I think even
> >> project
> >> >> with more than a million lines of code. CEDET is the only viable
> >> solution
> >> >> so far I found for real smart completion in Emacs. Other clang based
> >> >> solution is pretty limited: you can only get completion from system
> >> header
> >> >> and current directory, but not for your project. You have to add the
> >> >> include paths to tell Clang where your project include paths are, and
> >> you
> >> >> have to specify with absolute paths. It's really tedious.
> >> >>
> >> > No, it does not real smart. For example, please, try to
> >> > M-x semantic-ia-complete-symbol-menu
> >> > when you are in method implementation like this:
> >> > void Class::method()
> >> > {
> >> >   // M-x semantic-ia-complete-symbol-menu should show a menu
> >> >   // with all members in the scope. But nothing is shown.
> >> > }
> >> > Second example. Please, try to M-x semantic-ia-complete-symbol-menu
> >> > when you are in
> >> > void Class::method()
> >> > {
> >> >   method2(
> >> >   // M-x semantic-ia-complete-symbol-menu after the "(" will
> >> >   // freeze Emacs to do some of stupid thinking.
> >> >   // Terrible, horrible and sad. And nothing more.
> >> > }
> >> >
> >> > After this, I don't want to use CEDET without any sorry.
> >> > Sorry.
> >> >
> >> > --
> >> > // Dmitriy.
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > // Dmitriy.
> >
> >
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

> Any mention of CEDET always turns into this kind of discussion.

That's because CEDET is cool but hardly usable in practice unless your
exigence level is very low (for C++).

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

[Jai Dayal]

For standard C, I have no issues. Never used it for C++.

However, I must state, I fail to see why this thread must head down this
road.


On Wed, Aug 27, 2014 at 2:37 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
> > Any mention of CEDET always turns into this kind of discussion.
>
> That's because CEDET is cool but hardly usable in practice unless your
> exigence level is very low (for C++).
>
>
>

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

[Jai Dayal]

If there's something wrong with this guy's manual in regards to CEDET,
that's valid discussion. The usefulness, or lackthereof, of CEDET for C++
is a disjoint topic.


On Wed, Aug 27, 2014 at 2:42 PM, Jai Dayal <dayalsoap@gmail.com> wrote:

> For standard C, I have no issues. Never used it for C++.
>
> However, I must state, I fail to see why this thread must head down this
> road.
>
>
> On Wed, Aug 27, 2014 at 2:37 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Jai Dayal <dayalsoap@gmail.com> writes:
>>
>> > Any mention of CEDET always turns into this kind of discussion.
>>
>> That's because CEDET is cool but hardly usable in practice unless your
>> exigence level is very low (for C++).
>>
>>
>>
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

> If there's something wrong with this guy's manual in regards to CEDET,
> that's valid discussion. The usefulness, or lackthereof, of CEDET for C++
> is a disjoint topic.

Well, the subject mentions C++. Don't know if the guide mentions the
shortcomings CEDET has with C++, though. Otherwise, we'll have more
disappointed people around.

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

[Jai Dayal]

Okay, then what's the limit? Should we discuss Emacs' limitations as an IDE
all together to avoid disappointed people? His manual is about how to
properly setup the CEDET tool, it is not about how to evaluate CEDET to
determine if it's sufficient or not.


On Wed, Aug 27, 2014 at 2:52 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
> > If there's something wrong with this guy's manual in regards to CEDET,
> > that's valid discussion. The usefulness, or lackthereof, of CEDET for C++
> > is a disjoint topic.
>
> Well, the subject mentions C++. Don't know if the guide mentions the
> shortcomings CEDET has with C++, though. Otherwise, we'll have more
> disappointed people around.
>
>
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

> Okay, then what's the limit? Should we discuss Emacs' limitations as an IDE
> all together to avoid disappointed people? His manual is about how to
> properly setup the CEDET tool, it is not about how to evaluate CEDET to
> determine if it's sufficient or not.

If I see a "Guide for setting up X development environment", I'll assume
that the directions given on the guide will make me more productive
while working on X. For the specific case of CEDET/C++ combo, that's far
from assured. Giving a heads-up is appropiate here. Then each individual
can decide if they invest time on the effort.

In any case, thanks to the OP for writing the guide. I skimmed over it
and looks like worth reading even for a veteran Emacs/C++ dev like me.
It already mentions that CEDET is slow, (which I don't think it is the
real problem) but says nothing about its limitations when using the
built-in C++ parser.

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

[Jai Dayal]

>I'll assume
that the directions given on the guide will make me more productive
while working on X.

Sure, however, if X is inherently broken, that's a completely unrelated
discussion. The author of the manual here isn't even involved in CEDET.

>Giving a heads-up is appropiate here.

Then giving a heads-up in regards to Emacs is completely valid, and all
discussion, in this thread, on Emacs' short-comings are completely valid as
well? That's horrible logic.


On Wed, Aug 27, 2014 at 3:28 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
> > Okay, then what's the limit? Should we discuss Emacs' limitations as an
> IDE
> > all together to avoid disappointed people? His manual is about how to
> > properly setup the CEDET tool, it is not about how to evaluate CEDET to
> > determine if it's sufficient or not.
>
> If I see a "Guide for setting up X development environment", I'll assume
> that the directions given on the guide will make me more productive
> while working on X. For the specific case of CEDET/C++ combo, that's far
> from assured. Giving a heads-up is appropiate here. Then each individual
> can decide if they invest time on the effort.
>
> In any case, thanks to the OP for writing the guide. I skimmed over it
> and looks like worth reading even for a veteran Emacs/C++ dev like me.
> It already mentions that CEDET is slow, (which I don't think it is the
> real problem) but says nothing about its limitations when using the
> built-in C++ parser.
>
>
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

>>I'll assume
> that the directions given on the guide will make me more productive
> while working on X.
>
> Sure, however, if X is inherently broken, that's a completely unrelated
> discussion. The author of the manual here isn't even involved in CEDET.
>
>>Giving a heads-up is appropiate here.
>
> Then giving a heads-up in regards to Emacs is completely valid, and all
> discussion, in this thread, on Emacs' short-comings are completely valid as
> well? That's horrible logic.

Your interpretation of my words is terrible ;-) If someone gives advice
about using X, when X has serious shortcommings for the intended
purpose, discussing those shortcommings is quite relevant. If X is
mostly appropiate save for some minor details, mentioning those is just
a nice service for the user.

And no, it is not necessary to mention the bad ergonomics of Emacs'
keybindings whenever someone asks about how to configure Gnus for
reading e-mail.

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

[Jai Dayal]

No, my interpretation is correct.

If someone writes a manual on how to fix a Ford V8 engine, the discussion
on the engine's fuel efficiency and safety is completely irrelevant.
Following your logic, one could then turn the discussion into the utility
of driving in general, since it may otherwise lead to more disappointed
people.

His manual is about how to setup CEDET and use it. It's not about how to
evaluate CEDET in terms of productivity.

>And no, it is not necessary to mention the bad ergonomics of Emacs'
keybindings whenever someone asks about how to configure Gnus for
reading e-mail.

Why not? You just said that failing to mention the shortcomings can lead to
more disappointed people around. Following this "logic" failure to mention
Emacs' shortcomings during any discussion on Emacs features will lead to
more disappointed people around.


On Wed, Aug 27, 2014 at 4:06 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
> >>I'll assume
> > that the directions given on the guide will make me more productive
> > while working on X.
> >
> > Sure, however, if X is inherently broken, that's a completely unrelated
> > discussion. The author of the manual here isn't even involved in CEDET.
> >
> >>Giving a heads-up is appropiate here.
> >
> > Then giving a heads-up in regards to Emacs is completely valid, and all
> > discussion, in this thread, on Emacs' short-comings are completely valid
> as
> > well? That's horrible logic.
>
> Your interpretation of my words is terrible ;-) If someone gives advice
> about using X, when X has serious shortcommings for the intended
> purpose, discussing those shortcommings is quite relevant. If X is
> mostly appropiate save for some minor details, mentioning those is just
> a nice service for the user.
>
> And no, it is not necessary to mention the bad ergonomics of Emacs'
> keybindings whenever someone asks about how to configure Gnus for
> reading e-mail.
>
>
>
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

> No, my interpretation is correct.
>
> If someone writes a manual on how to fix a Ford V8 engine, the discussion
> on the engine's fuel efficiency and safety is completely irrelevant.
> Following your logic, one could then turn the discussion into the utility
> of driving in general, since it may otherwise lead to more disappointed
> people.
>
> His manual is about how to setup CEDET and use it. It's not about how to
> evaluate CEDET in terms of productivity.

The guide is about setting a C/C++ development environment.

That means explaining how to setup tools for increasing your
productivity. If one of the mentioned tools does not fit the bill for
one of the use cases (C++) it is relevant to mention the fact.

>>And no, it is not necessary to mention the bad ergonomics of Emacs'
> keybindings whenever someone asks about how to configure Gnus for
> reading e-mail.
>
> Why not? You just said that failing to mention the shortcomings can lead to
> more disappointed people around.

Exactly. If a C++ coder reads the guide and then expects from CEDET to
provide precise smart code completion like other popular IDEs do, most
likely he is set for a disappointment.

> Following this "logic" failure to mention
> Emacs' shortcomings during any discussion on Emacs features will lead to
> more disappointed people around.

You are a human being, not an 8-bit bot that is unable to interpret a
message beyond simple logic rules. That's what I assume from the readers
of help-gnu-emacs.

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

[Jai Dayal]

Actually, nope. When I decide to install an OS, say CentOS, I do not expect
to find a discussion on the pluses and minuses of CentOS on the
installation page. That's a completely different topic that has nothing to
do with CentOS installation.

Same with the actual Emacs page; on the installation section, there's no
discussion on the pluses and minuses of Emacs there in an attempt to avoid
having "disappointed people". When someone chooses to install something,
there's an understanding that they want to install it because they know
about it, or are wanting to try it out. Nobody with an IQ higher than 12
installs something for the first time, without reading about it, and
assumes it will magically work they way they want it, down to the very last
feature.

Can you find 10 installation manuals, or installation sections of a manual,
in English that discuss the actual pluses and minuses of the tool being
installed?


On Wed, Aug 27, 2014 at 4:57 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
> > No, my interpretation is correct.
> >
> > If someone writes a manual on how to fix a Ford V8 engine, the discussion
> > on the engine's fuel efficiency and safety is completely irrelevant.
> > Following your logic, one could then turn the discussion into the utility
> > of driving in general, since it may otherwise lead to more disappointed
> > people.
> >
> > His manual is about how to setup CEDET and use it. It's not about how to
> > evaluate CEDET in terms of productivity.
>
> The guide is about setting a C/C++ development environment.
>
> That means explaining how to setup tools for increasing your
> productivity. If one of the mentioned tools does not fit the bill for
> one of the use cases (C++) it is relevant to mention the fact.
>
> >>And no, it is not necessary to mention the bad ergonomics of Emacs'
> > keybindings whenever someone asks about how to configure Gnus for
> > reading e-mail.
> >
> > Why not? You just said that failing to mention the shortcomings can lead
> to
> > more disappointed people around.
>
> Exactly. If a C++ coder reads the guide and then expects from CEDET to
> provide precise smart code completion like other popular IDEs do, most
> likely he is set for a disappointment.
>
> > Following this "logic" failure to mention
> > Emacs' shortcomings during any discussion on Emacs features will lead to
> > more disappointed people around.
>
> You are a human being, not an 8-bit bot that is unable to interpret a
> message beyond simple logic rules. That's what I assume from the readers
> of help-gnu-emacs.
>
>
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

[snip]

> Can you find 10 installation manuals, or installation sections of a manual,
> in English that discuss the actual pluses and minuses of the tool being
> installed?

This is not about a product manual. It's a guide contributed to the
community by a user that describes tools and configurations with the
purpose of making others more productive if they write C/C++ code on
Emacs.

But whatever. You are not interested on understanding what I say. You
just want to win an argument. Feel free to proclaim yourself as the
winner, if that makes you happy. I'm done with this silly discussion.

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

[Rusi]

On Thursday, August 28, 2014 4:47:42 AM UTC+5:30, Jai Dayal wrote:
> Actually, nope. When I decide to install an OS, say CentOS, I do not expect
> to find a discussion on the pluses and minuses of CentOS on the
> installation page. That's a completely different topic that has nothing to
> do with CentOS installation.

In the FLOSS world what Jai is describing is the norm:

For any system X

- the X-folks talk of how to use and only its pros
- the anti-X folks have all the time to bash unconstructively
- a very short supply of balanced reasonable comparison and useful workarounds

Jai seems to think this is a good separation.

Personally I often find FLOSS folks at least as dishonest as the corporate types
[No surprise, given that human beings are the same...]

And diplomatic silence is often the most painful (for me) kind of dishonesty.

Example:

I joined the Linux audio list when I was having a hell of a time with some 
beast called pulseaudio. [I'm just an amateur musician... wanted to type
some music... NO clue or interest in pulseaudio... Evidently it was obstructing
something]

I got some vague 'pro-pulseaudio' response on how to solve my problem.
Nothing else. And my problem remained unsolved.

After hanging around the list for months I slowly discovered that
- most everyone hates pulse
- people are doing apt-get purge pulse as routine
- when that fails they are changing distros

The fact that it took me months to find that out is what I call
'dishonest diplomacy'

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

[Jai Dayal]

Actually, I would buy that argument if you asked for people's opinion on
Pulse and you got dishonest answers. Instead, you were asking for solutions
to a specific problem, and they were helping.

It's called "relevance"; it's something the Emacs community has a hard-time
understanding. That's why so many threads trail off and turn into
irrelevant discussions.

If you wanted to find out if Pulse Audio is an adequate tool, then you
should have sought opinions, not ask for help fixing bugs.


On Wed, Aug 27, 2014 at 11:30 PM, Rusi <rustompmody@gmail.com> wrote:

> On Thursday, August 28, 2014 4:47:42 AM UTC+5:30, Jai Dayal wrote:
> > Actually, nope. When I decide to install an OS, say CentOS, I do not
> expect
> > to find a discussion on the pluses and minuses of CentOS on the
> > installation page. That's a completely different topic that has nothing
> to
> > do with CentOS installation.
>
> In the FLOSS world what Jai is describing is the norm:
>
> For any system X
>
> - the X-folks talk of how to use and only its pros
> - the anti-X folks have all the time to bash unconstructively
> - a very short supply of balanced reasonable comparison and useful
> workarounds
>
> Jai seems to think this is a good separation.
>
> Personally I often find FLOSS folks at least as dishonest as the corporate
> types
> [No surprise, given that human beings are the same...]
>
> And diplomatic silence is often the most painful (for me) kind of
> dishonesty.
>
> Example:
>
> I joined the Linux audio list when I was having a hell of a time with some
> beast called pulseaudio. [I'm just an amateur musician... wanted to type
> some music... NO clue or interest in pulseaudio... Evidently it was
> obstructing
> something]
>
> I got some vague 'pro-pulseaudio' response on how to solve my problem.
> Nothing else. And my problem remained unsolved.
>
> After hanging around the list for months I slowly discovered that
> - most everyone hates pulse
> - people are doing apt-get purge pulse as routine
> - when that fails they are changing distros
>
> The fact that it took me months to find that out is what I call
> 'dishonest diplomacy'
>

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

[Óscar Fuentes]

Rusi <rustompmody@gmail.com> 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...]

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

OTOH, corporate types have, *on* *addition*, another motivator, which is
very powerful: greediness (which also implies increased social status,
etc.)

> And diplomatic silence is often the most painful (for me) kind of dishonesty.

Silence (diplomatic or apathic) is what allows dishonesty to do harm.
Diplomatic silence is cowardice by another name.

[snip]

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

[Rusi]

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 

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

[Jai Dayal]

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

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

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

[Óscar Fuentes]

solidius4747@gmail.com writes:

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

Absolutely. I build Clang+LLVM ToT every month or two.

> 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 guess that the machine have no enough memory and resorted to swapping.
Did you use GCC or Clang on that build? GCC requires much more memory.
Some source files of Clang are complex enough to require a good chunk of
memory even when compiled with Clang itself. OTOH, linking can be
memory-intensive, specially a debug build.

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

My experience with CEDET C++ smart completion (I try it once a year) is
that it often works on the most simple cases. It is quite good for C++
when used as "C with classes". However, it fails with more elaborate
cases. The fact that it works for some example that uses Boost proves
nothing, as Boost is not uniformly complex. Your screenshot about
boost::asio is not very demanding. Try something involving templates
(apart from the simple ones like std::vector) and you will see failures.
CEDET's C++ parser falls short of understanding namespace resolution and
other minefields of the C++ language. Let's not discuss modern features
like lambdas and variadic templates.

For doing correct smart completion for C++, parsing is not enough.
Semantic analysis is necessary. CEDET's parser does nothing of the sort.

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

That's good news indeed. However, please keep in mind that there are
huge differences on how people/teams/projects use C++. Something that
works for you may be insufficient for others, and in all cases C++ is
being used. Doing the job with a good compiler is the definitive
solution.

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

CEDET is fast enough for me. The problem is that it gives the wrong
answer too often.

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

FFI is in the "most wanted" feature list of the Emacs maintainers.
However, I don't see CEDET's team throwing away their Elisp parser and
start coding one on C/C++. They could use Clang's right away, or GCC's
once the modularization is completed, but they insist on their own's.

CEDET's problem with C++ is the extraordinary complexity of the
language. That's something that the handful of hackers working on CEDET,
no matter how talented they are, can't address on a reasonable
timeframe.

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

[Stefan Monnier]

> start coding one on C/C++. They could use Clang's right away, or GCC's
> once the modularization is completed, but they insist on their own's.

Actually, no, they don't insist on their own.  CEDET's infrastructure is
designed so you can use external tools.  The C/C++ support is not simply
replaced by Clang's support because many people don't use Clang (and
because it predates Clang, IIUC).
Also, AFAIK noone has written the CEDET binding to Clang yet, but
there's no technical difficulty doing it, AFAIK (it would probably be
easier with a good FFI, but it's probably doable even without an FFI).


        Stefan

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

[Dmitry]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Also, AFAIK noone has written the CEDET binding to Clang yet, but

David had, but it's not being actively developed, I've been told,
because it's unlikely to be accepted into Emacs, because of "politics".

http://sourceforge.net/p/cedet/mailman/message/27383453/

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

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> start coding one on C/C++. They could use Clang's right away, or GCC's
>> once the modularization is completed, but they insist on their own's.
>
> Actually, no, they don't insist on their own.

Well, if there exists one current plus another near-future solutions
which are vastly superior to their own parser, but they plan to continue
working on it, then yes, they are insisting on using their own parser.

>  CEDET's infrastructure is
> designed so you can use external tools.  The C/C++ support is not simply
> replaced by Clang's support because many people don't use Clang

What means "don't use Clang"? Is there some principled (cough!) stance
that forbids them from using Clang?

> (and because it predates Clang, IIUC).

This is not a reason for keeping with it, moreover as CEDET's
architecture (the one you refer to above) makes it easy to replace the
default parser.

> Also, AFAIK noone has written the CEDET binding to Clang yet,

See Dmitry's response to this.

[snip]

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

[Stefan Monnier]

>> CEDET's infrastructure is
>> designed so you can use external tools.  The C/C++ support is not simply
>> replaced by Clang's support because many people don't use Clang
> What means "don't use Clang"?

I think the meaning is pretty self-evident.

> Is there some principled (cough!) stance that forbids them from
> using Clang?

I don't really care why they don't use it.  I just know that many
people don't (and of course many people do, as well).


        Stefan

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

[David Engster]

Óscar Fuentes writes:
> However, I don't see CEDET's team throwing away their Elisp parser and
> start coding one on C/C++. They could use Clang's right away, or GCC's
> once the modularization is completed, but they insist on their own's.

Stop this, Óscar. I think you're very well aware that the clang binary
in itself only provides smart completions, nothing more. I *have* added
support for this in CEDET. I'm pretty sure you know that as well,
because I've already written this to you the last time this was
discussed.

What you are talking about is walking the AST using libclang/libtooling,
which is a whole different matter and nothing which one does "right
away". Just look at projects like rtags which do that, and see what it
entails.

This is just to set things straight for others which are reading this. I
have absolutely no interest in further discussing this with you.

-David

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

[Óscar Fuentes]

David Engster <deng@randomsample.de> writes:

> Óscar Fuentes writes:
>> However, I don't see CEDET's team throwing away their Elisp parser and
>> start coding one on C/C++. They could use Clang's right away, or GCC's
>> once the modularization is completed, but they insist on their own's.
>
> Stop this, Óscar. I think you're very well aware that the clang binary
> in itself only provides smart completions, nothing more. 

I'm aware of the possibilities provided by libclang, which go *far*
beyond than whatever the executable does.

> I *have* added
> support for this in CEDET. I'm pretty sure you know that as well,
> because I've already written this to you the last time this was
> discussed.

Yes, there are a number of packages that interact with Clang. That is
unrelated to the topic of this sub-thread: the usability of CEDET's
built-in C++ parser.

> What you are talking about is walking the AST using libclang/libtooling,
> which is a whole different matter and nothing which one does "right
> away". Just look at projects like rtags which do that, and see what it
> entails.

That's about 0.001% of the work required for implementing a C++
parser/analyzer.

> This is just to set things straight for others which are reading this. I
> have absolutely no interest in further discussing this with you.

Fair enough. And as I mentioned on that other discussion, this is not
about you, David. Please don't take this personally.

What irks me is that, whenever Emacs is compared to modern IDEs and
features like smart code completion, refactoring, advanced code
navigation and querying are discussed, CEDET is the Great Hand-waving
Enabler. Since CEDET was regarded as the solution by the community,
years passed, C++11 came, then C++14 and fact is that CEDET still can't
handle C++ code that was ordinary circa 1995. The net effect is that
Emacs is no longer competitive on the C++ realm and I cannot recommend
it to my C++ colleagues and students. The only hope is that some third
party package fixes this outside of the core Emacs development community
(be it on top of CEDET or not).

Of course, Emacs can also consider C++ a lost cause. After all, C++ has
just a fraction of the user base of Java.

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

[Jai Dayal]

Actually, the topic of this thread is not CEDET's usability, but rather a
manual on how to setup various Emacs IDE tools.

Oscar isn't too bright and believes in Jesus. Someone of "faith" can never
be convinced; faith is idiocy by definition.


On Fri, Aug 29, 2014 at 9:09 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> David Engster <deng@randomsample.de> writes:
>
> > Óscar Fuentes writes:
> >> However, I don't see CEDET's team throwing away their Elisp parser and
> >> start coding one on C/C++. They could use Clang's right away, or GCC's
> >> once the modularization is completed, but they insist on their own's.
> >
> > Stop this, Óscar. I think you're very well aware that the clang binary
> > in itself only provides smart completions, nothing more.
>
> I'm aware of the possibilities provided by libclang, which go *far*
> beyond than whatever the executable does.
>
> > I *have* added
> > support for this in CEDET. I'm pretty sure you know that as well,
> > because I've already written this to you the last time this was
> > discussed.
>
> Yes, there are a number of packages that interact with Clang. That is
> unrelated to the topic of this sub-thread: the usability of CEDET's
> built-in C++ parser.
>
> > What you are talking about is walking the AST using libclang/libtooling,
> > which is a whole different matter and nothing which one does "right
> > away". Just look at projects like rtags which do that, and see what it
> > entails.
>
> That's about 0.001% of the work required for implementing a C++
> parser/analyzer.
>
> > This is just to set things straight for others which are reading this. I
> > have absolutely no interest in further discussing this with you.
>
> Fair enough. And as I mentioned on that other discussion, this is not
> about you, David. Please don't take this personally.
>
> What irks me is that, whenever Emacs is compared to modern IDEs and
> features like smart code completion, refactoring, advanced code
> navigation and querying are discussed, CEDET is the Great Hand-waving
> Enabler. Since CEDET was regarded as the solution by the community,
> years passed, C++11 came, then C++14 and fact is that CEDET still can't
> handle C++ code that was ordinary circa 1995. The net effect is that
> Emacs is no longer competitive on the C++ realm and I cannot recommend
> it to my C++ colleagues and students. The only hope is that some third
> party package fixes this outside of the core Emacs development community
> (be it on top of CEDET or not).
>
> Of course, Emacs can also consider C++ a lost cause. After all, C++ has
> just a fraction of the user base of Java.
>
>
>

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

[Óscar Fuentes]

Jai Dayal <dayalsoap@gmail.com> writes:

> Oscar isn't too bright and believes in Jesus. Someone of "faith" can never
> be convinced; faith is idiocy by definition.

Maybe it is true that I'm not too bright. But I have a psycho stalker,
as if I were a celebrity!

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

[David Engster]

Óscar Fuentes writes:
> David Engster <deng@randomsample.de> writes:
>
>> Óscar Fuentes writes:
>>> However, I don't see CEDET's team throwing away their Elisp parser and
>>> start coding one on C/C++. They could use Clang's right away, or GCC's
>>> once the modularization is completed, but they insist on their own's.

[...]

>> This is just to set things straight for others which are reading this. I
>> have absolutely no interest in further discussing this with you.
>
> Fair enough. And as I mentioned on that other discussion, this is not
> about you, David. Please don't take this personally.

Your claim that we would insist on our own parser is simply false and
makes us look like bullheaded idiots. Now go tell me how I should not
take this personally.

If someone comes around with a libclang-based parser which fits neatly
into Semantic, I am the first one to merge it, and I know Eric wouldn't
oppose it, either. It would have to stay upstream for political reasons,
that much is true, but that's not my decision.

-David

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

[Óscar Fuentes]

David Engster <deng@randomsample.de> writes:

>> Fair enough. And as I mentioned on that other discussion, this is not
>> about you, David. Please don't take this personally.
>
> Your claim that we would insist on our own parser is simply false

That's great to know. My impression from the discussion on emacs-devel
was that you think that the built-in C++ parser is the way to go.

> and
> makes us look like bullheaded idiots.

No. It makes you look as someone with a view and confident about it, or
perhaps as someone who has fun working on what he likes, the way he
likes, as expected from anyone who contributes his work for free.

> Now go tell me how I should not take this personally.
>
> If someone comes around with a libclang-based parser which fits neatly
> into Semantic, I am the first one to merge it, and I know Eric wouldn't
> oppose it, either.

Being you the author of the current Clang support on CEDET and seeing
how you argued on its favor against the political decissions, that was
clear all along.

> It would have to stay upstream for political reasons,
> that much is true, but that's not my decision.

Yes, and neither this was addressed at you as the sole responsible of
steering CEDET. GNU's politics have a direct responsability on how Emacs
will evolve wrt those features.

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

[Rusi]

On Friday, August 29, 2014 11:36:35 AM UTC+5:30, David Engster wrote:
> �scar Fuentes writes:
> > However, I don't see CEDET's team throwing away their Elisp parser and
> > start coding one on C/C++. They could use Clang's right away, or GCC's
> > once the modularization is completed, but they insist on their own's.

> Stop this, �scar. I think you're very well aware that the clang binary
> in itself only provides smart completions, nothing more. I *have* added
> support for this in CEDET. I'm pretty sure you know that as well,
> because I've already written this to you the last time this was
> discussed.

> What you are talking about is walking the AST using libclang/libtooling,
> which is a whole different matter and nothing which one does "right
> away". Just look at projects like rtags which do that, and see what it
> entails.

rtags looks interesting.

Ive been thinking for a long time...
Once things like dbus stabilize, its only a question of time before 
the optimal solution is to parcel off code analysis to the right source
rather than emacs running in a (hopeless) catching up game of trying to do
as well as the language system itself.

So "what it entails" ?? What are the issues?

The one question I have straight off is "Is it generic?"

ie can rtags carry over to haskell/python etc?
[Of course assuming that the corresponding server for haskell/python etc
code analysis exist/can be written]

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

[Rusi]

On Thursday, August 28, 2014 5:57:44 PM UTC+5:30, Jai Dayal wrote:
> > 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?

The argument can cut both ways:
Consider that
a. The wars of the 20th century have been more terrible than all the
previous ones
b. The human propensity to wish to kill another is the same across millenia

We can only conclude that it is science and technology that is the
multiplying factor for the escalation.

Anyway this kind of blame game is becoming faintly ridiculous 
[and too OT to continue so should preferably stop with this post!]

I'd just reiterate what I said: "In my experience the scientific types
are more bigoted than the religious ones."

To convert this into a universally quantified: "All scientific persons
are more bigoted than religious ones" would be quite
ridiculous. Anyone interested can find any number of counterexamples
both ways.

Even a more nuanced statistical "It is more likely that..." is untenable 
without massively more data than we have at our disposal.

---------
And since this has now become too unrelated to emacs, I would like to 
drop out of this 'discussion'

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

[Jai Dayal]

That argument doesn't make sense, at all. This technology doesn't just
automatically kill people; it's controlled by people to kill people. It's
like blaming a homicide induced by stabbing on knife technology.

So, let me ask again: how many people have been killed in the name of
science vs. killed in the name of religion? It's pretty clear: very few
people have murdered someone else because "the science dictates this should
happen", when many people have killed other people simply because of
religious dogma.


On Thu, Aug 28, 2014 at 1:08 PM, Rusi <rustompmody@gmail.com> wrote:

> On Thursday, August 28, 2014 5:57:44 PM UTC+5:30, Jai Dayal wrote:
> > > 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?
>
> The argument can cut both ways:
> Consider that
> a. The wars of the 20th century have been more terrible than all the
> previous ones
> b. The human propensity to wish to kill another is the same across millenia
>
> We can only conclude that it is science and technology that is the
> multiplying factor for the escalation.
>
> Anyway this kind of blame game is becoming faintly ridiculous
> [and too OT to continue so should preferably stop with this post!]
>
> I'd just reiterate what I said: "In my experience the scientific types
> are more bigoted than the religious ones."
>
> To convert this into a universally quantified: "All scientific persons
> are more bigoted than religious ones" would be quite
> ridiculous. Anyone interested can find any number of counterexamples
> both ways.
>
> Even a more nuanced statistical "It is more likely that..." is untenable
> without massively more data than we have at our disposal.
>
> ---------
> And since this has now become too unrelated to emacs, I would like to
> drop out of this 'discussion'
>

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

[Marcin Borkowski]

Dnia 2014-08-28, o godz. 13:13:53
Jai Dayal <dayalsoap@gmail.com> napisał(a):

> So, let me ask again: how many people have been killed in the name of
> science vs. killed in the name of religion? It's pretty clear: very
> few people have murdered someone else because "the science dictates
> this should happen", when many people have killed other people simply
> because of religious dogma.

This is becoming totally off-topic, but to keep things precise:

1. I have yet to hear about a murder because "the science dictates this
should happen".  Unless we count in pseudo-science, that is, like the
"science" of racial purity of the German authorities during WW2 and
similar things.  Nobody's going to treat this seriously as "science",
though.

2. I have also yet to hear about a murder "because of religious
dogma".  I've heard about murders because of false interpretations
and/or false religions, but not about a single one because of a
*dogma*.

So for me, it's rather a 0:0 draw.  Of course, we *might* count in
pseudo-religious causes, but then why don't we count in
pseudo-science?  Both ways of counting are similarly dishonest.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

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

[Jai Dayal]

1) Hitler was a Christian.

2) What do you mean "false interpretations"? There's no canonical
interpretation of these religions, hence large factions exist between
almost all of them; killing under these "interpretations" is very much
dogma.

> So for me, it's rather a 0:0 draw.  Of course, we *might* count in
pseudo-religious causes, but then why don't we count in
pseudo-science?  Both ways of counting are similarly dishonest.

There is no such thing as pseudo-religion; it's all just religion.
Pseudo-science isn't even close to science.


On Thu, Aug 28, 2014 at 3:43 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl>
wrote:

> Dnia 2014-08-28, o godz. 13:13:53
> Jai Dayal <dayalsoap@gmail.com> napisał(a):
>
> > So, let me ask again: how many people have been killed in the name of
> > science vs. killed in the name of religion? It's pretty clear: very
> > few people have murdered someone else because "the science dictates
> > this should happen", when many people have killed other people simply
> > because of religious dogma.
>
> This is becoming totally off-topic, but to keep things precise:
>
> 1. I have yet to hear about a murder because "the science dictates this
> should happen".  Unless we count in pseudo-science, that is, like the
> "science" of racial purity of the German authorities during WW2 and
> similar things.  Nobody's going to treat this seriously as "science",
> though.
>
> 2. I have also yet to hear about a murder "because of religious
> dogma".  I've heard about murders because of false interpretations
> and/or false religions, but not about a single one because of a
> *dogma*.
>
> So for me, it's rather a 0:0 draw.  Of course, we *might* count in
> pseudo-religious causes, but then why don't we count in
> pseudo-science?  Both ways of counting are similarly dishonest.
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>
>

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

[Marcin Borkowski]

Dnia 2014-08-28, o godz. 15:47:03
Jai Dayal <dayalsoap@gmail.com> napisał(a):

> 1) Hitler was a Christian.

How *exactly* do you define "Christian" here?

> 2) What do you mean "false interpretations"? There's no canonical
> interpretation of these religions, hence large factions exist between
> almost all of them; killing under these "interpretations" is very much
> dogma.

Well, I know about at least one religion which actually has something
close to "canonical interpretation" (I'm neither an expert on
philosophy/theology, nor a native English speaker, but I suspect
that the word "doctrine" is more suitable here than "interpretation"
- hence my reservation.)  Consequently, "factions" existing within this
religion do indeed disagree on quite a lot of things (like: should
capital punishment be used nowadays, or: is free market the best idea
for economy, or: is Emacs better than Vim), but not the doctrine.

Also, could you please check the meaning of the word "dogma" in your
dictionary?

> > So for me, it's rather a 0:0 draw.  Of course, we *might* count in
> pseudo-religious causes, but then why don't we count in
> pseudo-science?  Both ways of counting are similarly dishonest.
> 
> There is no such thing as pseudo-religion; it's all just religion.
> Pseudo-science isn't even close to science.

Well, sir, you are entitled to have your personal opinions.  I'm
afraid, though, that both above sentences are not correct.  First of
all, I didn't use the word "pseudoreligion" - I was writing about
"pseudo-religious causes", which I tried to explain in the previous
paragraph (though the term was probably badly chosen).  Also, *if*
pseudo-science weren't (in some its aspects at least) close to science,
nobody would fall for it.  And actually some contemporary parts of the
so-called "science" are dangerously close to pseudo-science.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

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

[Rusi]

On Thursday, August 28, 2014 10:43:53 PM UTC+5:30, Jai Dayal wrote:
> That argument doesn't make sense, at all. This technology doesn't just
> automatically kill people; it's controlled by people to kill people. It's
> like blaming a homicide induced by stabbing on knife technology.

> So, let me ask again: how many people have been killed in the name of
> science vs. killed in the name of religion?

Ok I'll answer if you tell me what this has to do with emacs
[Of course if it really matters and its not to do with emacs we are welcome
to continue off-list]

> It's pretty clear: very few people have murdered someone else
> because "the science dictates this should happen", when many people
> have killed other people simply because of religious dogma.


Its good to know you do not need me to answer

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

[Thorsten Jolitz]

Rusi <rustompmody@gmail.com> writes:

> I'd just reiterate what I said: "In my experience the scientific types
> are more bigoted than the religious ones."

Indeed, looking at 100 years of German history one is inclined to ask:
why is science (or rather why are universities and other scientific
institutions) so eager to adapt to the actual power and ideology?

Packed with high-potentials with years of training in critical thinking,
they nevertheless not only adapt out of opportunism to the current
(dumb) doctrine, be it fachism (NSDAP), socialism/communism (SED), or
the recent politically correct gender-mainstreaming multi-culturalism,
they do it with enthusiasm.

Maybe scientific types are not really bigoted, but actually religious
types too - desperately looking for some kind of mass movement they can
be part of.

-- 
cheers,
Thorsten

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

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Jai Dayal <dayalsoap@gmail.com> writes:
>
>> Any mention of CEDET always turns into this kind of discussion.
>
> That's because CEDET is cool but hardly usable in practice unless your
> exigence level is very low (for C++).

I take that back.

The main reason is that people is desperate for something that gives
Emacs the productivity features of modern IDEs, discover CEDET, gets
excited and then... *ploof*.

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

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

() Tu Hoang Do <solidius4747@gmail.com>
() Wed, 27 Aug 2014 20:18:27 +0700

   CEDET is not slow.

Maybe it's time someone implemented a MEEPS
(Millions of Emacs Evaluations Per Second) counter.
Then, we can qualify that statement w/ "on a N MEEPS"
system and people on old M MEEPS (M<<N) computers can
snort w/ wonder...  :-D

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[solidius4747]

Vào 21:39:59 UTC+7 Thứ tư, ngày 27 tháng tám năm 2014, Thien-Thi Nguyen đã viết:
> () Tu Hoang Do <solidius4747@gmail.com>
> 
> () Wed, 27 Aug 2014 20:18:27 +0700
> 
> 
> 
>    CEDET is not slow.
> 
> 
> 
> Maybe it's time someone implemented a MEEPS
> 
> (Millions of Emacs Evaluations Per Second) counter.
> 
> Then, we can qualify that statement w/ "on a N MEEPS"
> 
> system and people on old M MEEPS (M<<N) computers can
> 
> snort w/ wonder...  :-D
> 
> 
> 
> -- 
> 
> Thien-Thi Nguyen
> 
>    GPG key: 4C807502
> 
>    (if you're human and you know it)
> 
>       read my lisp: (responsep (questions 'technical)
> 
>                                (not (via 'mailing-list)))
> 
>                      => nil

Because real parsing takes time and such a task, while possible using Emacs Lisp, but is too much for current Emacs implementation. CEDET does some nice optimizations to speed it up as fast as it can: idle parsing, caching and incremental parsing to reduce computational time. Consider someone using Clang to generate tag database: https://github.com/drothlis/clang-ctags#performance:

"Running clang-ctags over a much larger input, such as the entire llvm C/C++ sources (7k files, 1.8 million lines of code) took 98 minutes and a peak memory usage of 140MB."

It's just 1.8 million lines of code. And that's Clang. GNU Global only needs a few minutes to generate tag database for Linux kernel, which is more than 14 million lines of code and more than 40k files. Do you say Clang is worse than GNU Global?

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

[Óscar Fuentes]

solidius4747@gmail.com writes:

> Because real parsing takes time and such a task, while possible using
> Emacs Lisp, but is too much for current Emacs implementation. CEDET
> does some nice optimizations to speed it up as fast as it can: idle
> parsing, caching and incremental parsing to reduce computational time.
> Consider someone using Clang to generate tag database:
> https://github.com/drothlis/clang-ctags#performance:
>
> "Running clang-ctags over a much larger input, such as the entire llvm
> C/C++ sources (7k files, 1.8 million lines of code) took 98 minutes
> and a peak memory usage of 140MB."
>
> It's just 1.8 million lines of code. And that's Clang.

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

> GNU Global only
> needs a few minutes to generate tag database for Linux kernel, which
> is more than 14 million lines of code and more than 40k files. Do you
> say Clang is worse than GNU Global?

I'll say that parsing those 1.8 MLoc of C++ code is much more demanding
than parsing 14 MLoc of C code. And the level of analysis GNU Global
does is incomparable with a real compiler and it is a long stretch to
put it on the same tool category as Clang (or even Semantic's own
parser.)

GNU Global has its uses, but C++ auto completion needs Clang, which is
accurate but slow. I can't see how CEDET could be acceptably fast and
accurate at the same time.