c/c++ project management and debugging

c/c++ project management and debugging

[Rajinder Yadav]

up to now i've been using emacs for ruby on rails, i want to get setup 
so i can also do c/c++ development

i come from a visualstudio ide background for c++ stuff, how can I setup 
emacs to integrate the gnu tool chain, such that i can have emacs 
generate makefiles and do the builds

also how can i get a gui like ide gdb setup for debugging code

-- 
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-23-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.3

Re: c/c++ project management and debugging

[Andrea Crotti]

Rajinder Yadav <devguy.ca@gmail.com> writes:

> up to now i've been using emacs for ruby on rails, i want to get setup
> so i can also do c/c++ development
>
> i come from a visualstudio ide background for c++ stuff, how can I
> setup emacs to integrate the gnu tool chain, such that i can have
> emacs generate makefiles and do the builds
>
> also how can i get a gui like ide gdb setup for debugging code

Why, does visualstudio integrates with the gnu tool chain :O?
I guess not, but that's what I understood from your sentences...

Anyway with Cedet you can do a lot of stuff.
It doesn't however generats any makefile, but if you learn to write them
is not time wasted at all...

Gdb integration works quite well already, the only important parameter
for gdb imho is (setq gdb-many-windows t)

and then just try something you'll see if you like it.

Re: c/c++ project management and debugging

[Suvayu Ali]

On Monday 20 December 2010 05:47 AM, Andrea Crotti wrote:
> Anyway with Cedet you can do a lot of stuff.
> It doesn't however generats any makefile, but if you learn to write them
> is not time wasted at all...

I believe that is incorrect[fn:1]. However I have to say I haven't tried
it out, so I can't testify how good/easy it is is to generate
Makefiles. On the other hand I have been using CEDET to program within a
few C/C++ frameworks, and it seems to work quite well.

Footnotes:
[fn:1] [[info:ede:Creating%20a%20project][info:ede:Creating a project]]

-- 
Suvayu

Open source is the future. It sets us free.

Re: c/c++ project management and debugging

[despen]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> On Monday 20 December 2010 05:47 AM, Andrea Crotti wrote:
>> Anyway with Cedet you can do a lot of stuff.
>> It doesn't however generats any makefile, but if you learn to write them
>> is not time wasted at all...
>
> I believe that is incorrect[fn:1]. However I have to say I haven't tried
> it out, so I can't testify how good/easy it is is to generate
> Makefiles. On the other hand I have been using CEDET to program within a
> few C/C++ frameworks, and it seems to work quite well.
>
> Footnotes:
> [fn:1] [[info:ede:Creating%20a%20project][info:ede:Creating a project]]

Hmm,  I'd no sooner let a tool create a Makefile, than I'd use a code
generator to create C++.

I _LIKE_ creating hand worked Makefiles.

I have a lot more targets than just executables.
They're used to create documentation and run tests too.

Re: c/c++ project management and debugging

[Jason Earl]

On Mon, Dec 20 2010, despen@verizon.net wrote:

> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>
>> On Monday 20 December 2010 05:47 AM, Andrea Crotti wrote:
>>> Anyway with Cedet you can do a lot of stuff.
>>> It doesn't however generats any makefile, but if you learn to write them
>>> is not time wasted at all...
>>
>> I believe that is incorrect[fn:1]. However I have to say I haven't tried
>> it out, so I can't testify how good/easy it is is to generate
>> Makefiles. On the other hand I have been using CEDET to program within a
>> few C/C++ frameworks, and it seems to work quite well.
>>
>> Footnotes:
>> [fn:1] [[info:ede:Creating%20a%20project][info:ede:Creating a project]]
>
> Hmm, I'd no sooner let a tool create a Makefile, than I'd use a code
> generator to create C++.
>
> I _LIKE_ creating hand worked Makefiles.
>
> I have a lot more targets than just executables.  They're used to
> create documentation and run tests too.

CEDET's EDE stuff can handle documentation targets (and a whole lot
more).  In fact, I even have one small project where it reads my
Automake files directly.

Personally, I think that using CEDET for this stuff has two advantages.
The first is that it can generate a lot of the boilerplate for you.  You
might like generating Makefiles by hand, but that is hardly universal.
EDE generates really nice Makefiles will all sorts of targets that you
probably wouldn't generate yourself.  For example, it will generate
rules to create a distribution of your source, and rules to upload that
source to the project webspace (including updating the hosted
documentation).  The front end for all of this is similar to customize,
and the help strings on the various variables are actually quite
helpful.  It also plays nicely with Automake, and no one professes to
love writing those things by hand :).

The second advantage to using EDE is that it gives Emacs an idea as to
your project structure.  This opens a whole world of opportunities.

If you are using Emacs from bzr it is even easy to get started.  Go to
the "Tools" menu and choose "Project Support (EDE)."

Jason

Re: c/c++ project management and debugging

[Rajinder Yadav]

On Mon, Dec 20, 2010 at 8:47 AM, Andrea Crotti
<andrea.crotti.0@gmail.com> wrote:
> Rajinder Yadav <devguy.ca@gmail.com> writes:
>
>> up to now i've been using emacs for ruby on rails, i want to get setup
>> so i can also do c/c++ development
>>
>> i come from a visualstudio ide background for c++ stuff, how can I
>> setup emacs to integrate the gnu tool chain, such that i can have
>> emacs generate makefiles and do the builds
>>
>> also how can i get a gui like ide gdb setup for debugging code
>
> Why, does visualstudio integrates with the gnu tool chain :O?
> I guess not, but that's what I understood from your sentences...

no i wanted emacs to integrate with the gnu tool chain

> Anyway with Cedet you can do a lot of stuff.
> It doesn't however generats any makefile, but if you learn to write them
> is not time wasted at all...

yes i already have cedet installed and working, but i would rather not
write makefiles by hand. i understand there is also autoconf that can
be used to generate makefiles, possible that's a better way to go,
still i don't feel like investing the time to learn about autoconf at
this point and time

>
> Gdb integration works quite well already, the only important parameter
> for gdb imho is (setq gdb-many-windows t)
>
> and then just try something you'll see if you like it.

yes i discovered this gdb setting on the emacs-fu blog, however i have
2 questions

1) when i have EBC opened gdb-many-windows end up looking like a mess,
is there a way to get it to work with EBC?

2) i can't figure out how to set breakpoint, can't i simple click
someone in the source window to add a bp?


--
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1

Re: c/c++ project management and debugging

[Andrea Crotti]

Rajinder Yadav <devguy.ca@gmail.com> writes:


> yes i already have cedet installed and working, but i would rather not
> write makefiles by hand. i understand there is also autoconf that can
> be used to generate makefiles, possible that's a better way to go,
> still i don't feel like investing the time to learn about autoconf at
> this point and time

There is also cmake otherwise.
The problem is that or
- you learn a bit the autoconf skills you need (doesn't take long)
  and finally write your own build systems
- you'll be stuck forever with what other people (microsoft/cedet)
  thik is a good idea, and normally it isn't

Using emacs I think it doesn't make any sense to look for tools that
write makefiles for you...

>
> yes i discovered this gdb setting on the emacs-fu blog, however i have
> 2 questions
>
> 1) when i have EBC opened gdb-many-windows end up looking like a mess,
> is there a way to get it to work with EBC?
>
> 2) i can't figure out how to set breakpoint, can't i simple click
> someone in the source window to add a bp?
>

For a breakpoint you can click, use the space bar or the standard gdb:
"b File.cpp:#line" or "b Class::function"

Re: c/c++ project management and debugging

[Rajinder Yadav]

On 10-12-20 08:28 PM, Andrea Crotti wrote:
> Rajinder Yadav<devguy.ca@gmail.com>  writes:
>
>
>> yes i already have cedet installed and working, but i would rather not
>> write makefiles by hand. i understand there is also autoconf that can
>> be used to generate makefiles, possible that's a better way to go,
>> still i don't feel like investing the time to learn about autoconf at
>> this point and time
>
> There is also cmake otherwise.
> The problem is that or
> - you learn a bit the autoconf skills you need (doesn't take long)
>    and finally write your own build systems
> - you'll be stuck forever with what other people (microsoft/cedet)
>    thik is a good idea, and normally it isn't
>
> Using emacs I think it doesn't make any sense to look for tools that
> write makefiles for you...


Andrea, thanks for your reply!

My reply here is not a direct response to you, but what i feel in 
general (a windows IDE guy in a Linux command line world)

I don't quite understand the rational against emacs + auto makefile 
generation, it kind of hinders progress imho? if someone doesn't like 
the way emacs or netbean does things (for them) with makefiles, they 
always have the choice of doing it by hand, that is the beauty of having 
more choices, so stop taking away my choices if I simply ask or enquire 
for feature y!

guys like me from the visual IDE environment will have a smaller barrier 
to entry as a result, overtime we will pickup said skills of making a 
makefile by hand, using autoconf or cmake, etc.

i've never had the need to create a makefile or edit one by hand when i 
code using visualstudio, all i care about is coding my project in C++ 
and getting on with life. people like me need a bridge when we come over 
to the open source world, when we start using linux or emacs, etc. most 
of the time we are met with ridicule about how absurd our needs and 
demands are, so opportunity is lost when some decide why bother with 
open source, etc. el

i love ruby on rails hacking, i love doing everything from the command 
line, it's more faster and efficient coding a rails app when compared to 
doing it with netbeans + ide, or whatever IDE is out there!

i can tell you i spent countless hours searching the net and reading 
stuff just to figure out how to use emacs and get it setup with stuffs 
like ido, ecb, cedet and yasnippet learning all the key binding and how 
to edit the .emacs files, the barrier to entry to become more efficient 
with "emacs" is high

i like having ecb for file browsing, i don't always use it, sometimes i 
use the file searching power of ido, but i have a choice when to use 
which in emacs

i am very grateful to the open source community that has made emacs a 
better tool for me and many more that help answer all my questions on 
mailing list or write blogs.

>>
>> yes i discovered this gdb setting on the emacs-fu blog, however i have
>> 2 questions
>>
>> 1) when i have EBC opened gdb-many-windows end up looking like a mess,
>> is there a way to get it to work with EBC?
>>
>> 2) i can't figure out how to set breakpoint, can't i simple click
>> someone in the source window to add a bp?
>>
>
> For a breakpoint you can click, use the space bar or the standard gdb:
> "b File.cpp:#line" or "b Class::function"
>
>

clicking for me doesn't set the breakpoint when i have the source file 
open in the buffer, i am still in edit mode?

i see many gdb windows, but where do I type, b File.cpp:#line ??

here is what i do

1. open a simple .cpp source file in emacs, a hello world file in C++
2. m-x gdb

source buffer disappears, replaced by gdb buffer

3 m-x gdb-many-windows
i still don't see my source code window? now where do i click to set a 
break point?

if i switch the gdb buffer to display my source code buffer, i can't 
type in the gdb command while still looking at my source buffer? how is 
one to work in this kind of setup

can i not have a source buffer and a gdb buffer open at the same time, 
still where do i click to set the break point?

Thanks

-- 
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-23-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.3

Re: c/c++ project management and debugging

[Andrea Crotti]

Rajinder Yadav <devguy.ca@gmail.com> writes:

> Andrea, thanks for your reply!
>
> My reply here is not a direct response to you, but what i feel in
> general (a windows IDE guy in a Linux command line world)
>
> I don't quite understand the rational against emacs + auto makefile
> generation, it kind of hinders progress imho? if someone doesn't like
> the way emacs or netbean does things (for them) with makefiles, they
> always have the choice of doing it by hand, that is the beauty of
> having more choices, so stop taking away my choices if I simply ask or
> enquire for feature y!
>
> guys like me from the visual IDE environment will have a smaller
> barrier to entry as a result, overtime we will pickup said skills of
> making a makefile by hand, using autoconf or cmake, etc.
>
> i've never had the need to create a makefile or edit one by hand when
> i code using visualstudio, all i care about is coding my project in
> C++ and getting on with life. people like me need a bridge when we
> come over to the open source world, when we start using linux or
> emacs, etc. most of the time we are met with ridicule about how absurd
> our needs and demands are, so opportunity is lost when some decide why
> bother with open source, etc. el
>
> i love ruby on rails hacking, i love doing everything from the command
> line, it's more faster and efficient coding a rails app when compared
> to doing it with netbeans + ide, or whatever IDE is out there!
>
> i can tell you i spent countless hours searching the net and reading
> stuff just to figure out how to use emacs and get it setup with stuffs
> like ido, ecb, cedet and yasnippet learning all the key binding and
> how to edit the .emacs files, the barrier to entry to become more
> efficient with "emacs" is high
>
> i like having ecb for file browsing, i don't always use it, sometimes
> i use the file searching power of ido, but i have a choice when to use
> which in emacs
>
> i am very grateful to the open source community that has made emacs a
> better tool for me and many more that help answer all my questions on
> mailing list or write blogs.

Sure I perfectly understand your point of view, I also agree that it's
better to proceed step by step with everything, or we'll only get
frustrated by the this overcomplicated world.

I just mean that for a software developer programming is not enough, you
must also know your compiler well enough, and your build system.
Otherwise you will:
1. miss many opportunities to write/test much better your code
2. feel like you're using a black box, and be stuck on some product to
   build code that maybe would be perfectly portable everywhere.

> clicking for me doesn't set the breakpoint when i have the source file
> open in the buffer, i am still in edit mode?
>
> i see many gdb windows, but where do I type, b File.cpp:#line ??
>
> here is what i do
>
> 1. open a simple .cpp source file in emacs, a hello world file in C++
> 2. m-x gdb
>
> source buffer disappears, replaced by gdb buffer
>
> 3 m-x gdb-many-windows
> i still don't see my source code window? now where do i click to set a
> break point?
>
> if i switch the gdb buffer to display my source code buffer, i can't
> type in the gdb command while still looking at my source buffer? how
> is one to work in this kind of setup
>
> can i not have a source buffer and a gdb buffer open at the same time,
> still where do i click to set the break point?
>
> Thanks

Sorry clicking doesn't work for me either, what you should do is the
following

evaluate this or set it in your .emacs:
(setq gdb-many-windows t)

g++ -ggdb hello.cpp
M-x gdb RET
And it will prompt you how to run gdb, for example:
gdb --annotate=3 a.out

the annotate is very important otherwise emacs will not be able to
follow the execution.

then you should have on top the gud/gdb buffer, where you can type very
normal gdb commands.
Otherwise you open any source file and with "C-x space" you should be
able to set your breakpoints.

To know more just look in the GUD menu on top or the info page.

Re: c/c++ project management and debugging

[Rajinder Yadav]

On 10-12-20 08:28 PM, Andrea Crotti wrote:
> Rajinder Yadav<devguy.ca@gmail.com>  writes:
>
>
>> yes i already have cedet installed and working, but i would rather not
>> write makefiles by hand. i understand there is also autoconf that can
>> be used to generate makefiles, possible that's a better way to go,
>> still i don't feel like investing the time to learn about autoconf at
>> this point and time
>
> There is also cmake otherwise.
> The problem is that or
> - you learn a bit the autoconf skills you need (doesn't take long)
>    and finally write your own build systems
> - you'll be stuck forever with what other people (microsoft/cedet)
>    thik is a good idea, and normally it isn't

one other point i forgot to mention with open source, you are never 
stuck with what someone else thinks "at the time" is a good idea, all 
ideas grow organically over time, just like emacs has!

unfortunately for me i cannot make a contribution to emacs due to lack 
of time and lack of skills with LISP programming, thus i can only 
encourage and shape by communication

>
> Using emacs I think it doesn't make any sense to look for tools that
> write makefiles for you...
>
>>
>> yes i discovered this gdb setting on the emacs-fu blog, however i have
>> 2 questions
>>
>> 1) when i have EBC opened gdb-many-windows end up looking like a mess,
>> is there a way to get it to work with EBC?
>>
>> 2) i can't figure out how to set breakpoint, can't i simple click
>> someone in the source window to add a bp?
>>
>
> For a breakpoint you can click, use the space bar or the standard gdb:
> "b File.cpp:#line" or "b Class::function"
>
>


-- 
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-23-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.3

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 12:00 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
> i've never had the need to create a makefile or edit one by hand when i
> code using visualstudio, all i care about is coding my project in C++
> and getting on with life.

You don't know what a professional IDE is then, and why Emacs isn't up
to the task.

If you are doing professional C++ development, then you are tweaking
your project settings all the time.  The VC++ Project Settings dialog
is just a wrapper on top of a "Makefile" kind-of generator.  What VC++
does that Emacs doesn't is setting default values which work unless
you have special requirements.  That's why you felt that all you had
to care about was coding your project in C++.  Development in Emacs
does not give such luxury.

> i love ruby on rails hacking, i love doing everything from the command
> line, it's more faster and efficient coding a rails app when compared to
> doing it with netbeans + ide, or whatever IDE is out there!

Obviously, for hobbyists, an IDE is overkill.

I'd really like this madness of recommending Emacs as an IDE to stop.
When programmers hadn't anything better than an editor and/or programs
were simpler, that made sense.  It doesn't make sense anymore.

Again, this is not a fault of Emacs developers: they are not "selling"
Emacs as an IDE,  over-enthusiastic user are doing that.  Such users
are pushing Emacs way beyond what it can handle.

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 1:10 pm, Elena <egarr...@gmail.com> wrote:
> On Dec 21, 12:00 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
>
> > i've never had the need to create a makefile or edit one by hand when i
> > code using visualstudio, all i care about is coding my project in C++
> > and getting on with life.
>
> You don't know what a professional IDE is then, and why Emacs isn't up
> to the task.
>
> If you are doing professional C++ development, then you are tweaking
> your project settings all the time.  The VC++ Project Settings dialog
> is just a wrapper on top of a "Makefile" kind-of generator.  What VC++
> does that Emacs doesn't is setting default values which work unless
> you have special requirements.  That's why you felt that all you had
> to care about was coding your project in C++.  Development in Emacs
> does not give such luxury.
>
> > i love ruby on rails hacking, i love doing everything from the command
> > line, it's more faster and efficient coding a rails app when compared to
> > doing it with netbeans + ide, or whatever IDE is out there!
>
> Obviously, for hobbyists, an IDE is overkill.
>
> I'd really like this madness of recommending Emacs as an IDE to stop.
> When programmers hadn't anything better than an editor and/or programs
> were simpler, that made sense.  It doesn't make sense anymore.
>
> Again, this is not a fault of Emacs developers: they are not "selling"
> Emacs as an IDE,  over-enthusiastic user are doing that.  Such users
> are pushing Emacs way beyond what it can handle.

Oh, and makefiles are so old-school.  Upgrade yourself to something
more modern an IDE-friendly.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>
> Oh, and makefiles are so old-school.  Upgrade yourself to something
> more modern an IDE-friendly.

What are you talking about, old-school :D?

Plain makefiles maybe because they're not easily portable, but
autoconf/cmake are used by I think all from small to huge opensource
projects.

About the rest, I really don't think an IDE is better/faster than a good
customized emacs.

I see how my collegueas work with those IDE and frankly I feel sorry for
them, and I can do anything twice as fast more or less ;)

Re: c/c++ project management and debugging

[Richard Riley]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> Elena <egarrulo@gmail.com> writes:
>
>>
>> Oh, and makefiles are so old-school.  Upgrade yourself to something
>> more modern an IDE-friendly.
>
> What are you talking about, old-school :D?
>
> Plain makefiles maybe because they're not easily portable, but
> autoconf/cmake are used by I think all from small to huge opensource
> projects.


autoconf is a dinosaur. I understood there are moves to make it
obsolete?

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 3:06 pm, Andrea Crotti <andrea.crott...@gmail.com> wrote:
> Elena <egarr...@gmail.com> writes:
>
> > Oh, and makefiles are so old-school.  Upgrade yourself to something
> > more modern an IDE-friendly.
>
> What are you talking about, old-school :D?
>
> Plain makefiles maybe because they're not easily portable, but
> autoconf/cmake are used by I think all from small to huge opensource
> projects.

That's what I was talking about: makefiles are akin to assembly
language, with shell commands being the corresponding machine-
language.  You should be "compiling" an higher-level language (that
is, a language which understands projects: CMake, etc.) to makefiles.

>
> About the rest, I really don't think an IDE is better/faster than a good
> customized emacs.

That's the problem: every Emacs power user seems to be chasing this
holy grail of a greatly customized Emacs, but I have yet to see a
customized Emacs matching a customized IDE.

> I see how my collegueas work with those IDE and frankly I feel sorry for
> them, and I can do anything twice as fast more or less ;)

That's their fault, not their IDE's.  Comparing an heavily customized
Emacs to a vanilla IDE is not fair.  Moreover, I can edit the same
source file both in Emacs and Visual Studio, and each side is just an
hot-key away.  I use each tool for its intended purpose: the text-
editor (Emacs) to edit text, the code-editor (IDE) to edit code.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> That's the problem: every Emacs power user seems to be chasing this
> holy grail of a greatly customized Emacs, but I have yet to see a
> customized Emacs matching a customized IDE.

IDE are not customizable.

Providing a non generic customization language (as some IDE I had to
suffer) doesn't count.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 9:43 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Elena <egarr...@gmail.com> writes:
> > That's the problem: every Emacs power user seems to be chasing this
> > holy grail of a greatly customized Emacs, but I have yet to see a
> > customized Emacs matching a customized IDE.
>
> IDE are not customizable.
>
> Providing a non generic customization language (as some IDE I had to
> suffer) doesn't count.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> A bad day in () is better than a good day in {}.

Is Emacs Lisp more generic than - let's say - VBScript or Javascript?
Or than writing plugins.  Even if I admit that writing plugins is
cumbersome and Lisp is the one true extension language, I don't think
so.

Re: c/c++ project management and debugging

[Richard Riley]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Elena <egarrulo@gmail.com> writes:
>
>> That's the problem: every Emacs power user seems to be chasing this
>> holy grail of a greatly customized Emacs, but I have yet to see a
>> customized Emacs matching a customized IDE.
>
> IDE are not customizable.


Huh?

Of course they are.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Richard Riley <rileyrg@googlemail.com> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> Elena <egarrulo@gmail.com> writes:
>>
>>> That's the problem: every Emacs power user seems to be chasing this
>>> holy grail of a greatly customized Emacs, but I have yet to see a
>>> customized Emacs matching a customized IDE.
>>
>> IDE are not customizable.
>
>
> Huh?
>
> Of course they are.

Close to none, compared to emacs.  The main problem is that they either
propose a fixed set of options ("preferences"), or if they propose a
"programming" language, it's a half-backed proprietary languages, often
not even Turing-complete.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 23, 12:45 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Richard Riley <rile...@googlemail.com> writes:
> > "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>
> >> Elena <egarr...@gmail.com> writes:
>
> >>> That's the problem: every Emacs power user seems to be chasing this
> >>> holy grail of a greatly customized Emacs, but I have yet to see a
> >>> customized Emacs matching a customized IDE.
>
> >> IDE are not customizable.
>
> > Huh?
>
> > Of course they are.
>
> Close to none, compared to emacs.  The main problem is that they either
> propose a fixed set of options ("preferences"), or if they propose a
> "programming" language, it's a half-backed proprietary languages, often
> not even Turing-complete.

False.  IDE plugins are developed in Turing-complete languages, thus
they can do whatever they please.  The scripting language embedded in
most IDEs is just for less-demanding tasks.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> On Dec 23, 12:45 am, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> Richard Riley <rile...@googlemail.com> writes:
>> > "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>>
>> >> Elena <egarr...@gmail.com> writes:
>>
>> >>> That's the problem: every Emacs power user seems to be chasing this
>> >>> holy grail of a greatly customized Emacs, but I have yet to see a
>> >>> customized Emacs matching a customized IDE.
>>
>> >> IDE are not customizable.
>>
>> > Huh?
>>
>> > Of course they are.
>>
>> Close to none, compared to emacs.  The main problem is that they either
>> propose a fixed set of options ("preferences"), or if they propose a
>> "programming" language, it's a half-backed proprietary languages, often
>> not even Turing-complete.
>
> False.  IDE plugins are developed in Turing-complete languages, thus
> they can do whatever they please.  The scripting language embedded in
> most IDEs is just for less-demanding tasks.

Not to mention that sometimes, the customization part of the IDE, is
sold as a separate products, with separate license tokens, and therefore
you are not necessarily able to use it as routinely as the main, frozen
IDE.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 23, 8:38 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Elena <egarr...@gmail.com> writes:
> > On Dec 23, 12:45 am, "Pascal J. Bourguignon" <p...@informatimago.com>
> > wrote:
> >> Richard Riley <rile...@googlemail.com> writes:
> >> > "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>
> >> >> Elena <egarr...@gmail.com> writes:
>
> >> >>> That's the problem: every Emacs power user seems to be chasing this
> >> >>> holy grail of a greatly customized Emacs, but I have yet to see a
> >> >>> customized Emacs matching a customized IDE.
>
> >> >> IDE are not customizable.
>
> >> > Huh?
>
> >> > Of course they are.
>
> >> Close to none, compared to emacs. The main problem is that they either
> >> propose a fixed set of options ("preferences"), or if they propose a
> >> "programming" language, it's a half-backed proprietary languages, often
> >> not even Turing-complete.
>
> > False.  IDE plugins are developed in Turing-complete languages, thus
> > they can do whatever they please.  The scripting language embedded in
> > most IDEs is just for less-demanding tasks.
>
> Not to mention that sometimes, the customization part of the IDE, is
> sold as a separate products, with separate license tokens, and therefore
> you are not necessarily able to use it as routinely as the main, frozen
> IDE.

This is a different issue.  However, that should make us appreciate
even more Emacs being free in every sense.

Re: c/c++ project management and debugging

[Richard Riley]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>
>>> Elena <egarrulo@gmail.com> writes:
>>>
>>>> That's the problem: every Emacs power user seems to be chasing this
>>>> holy grail of a greatly customized Emacs, but I have yet to see a
>>>> customized Emacs matching a customized IDE.
>>>
>>> IDE are not customizable.
>>
>>
>> Huh?
>>
>> Of course they are.
>
> Close to none, compared to emacs.  The main problem is that they
> either

Compare to emacs this is true.

But nearly all allow you to configure the tools they use to one extent or
another. Eclipse is a VERY customisable IDE. The key is the word
"integrated" however.

Point of order : I refer to emacs as an IDE although many think its
not. Its certainly very weak in these areas (out of the box or unless
you're an elisp guru):-

project management (cedet is simply too complex and it seems rarely
used)
dependency management (really part of above)
code navigation (tags dont cut it and cedet is, well, complex)
context help
templates and smart parameters (inline code completions - and I dont
mean a tab key murdering static template mechanism like yasnippet)
context help
mixed mode programming (php/html for example)
java and Javascript
Python (no one seems to know which way to go here)

> propose a fixed set of options ("preferences"), or if they propose a
> "programming" language, it's a half-backed proprietary languages, often
> not even Turing-complete.

I would agree here. I use emacs. But this doesnt mean I think its a good
programming "IDE" in the usual sense of it. Certainly GUD/GDB seemed to
have got worse not better last time I used it. The true benefits Emacs
brings is in its "wholesomeness" for want of a better word. I like using
the one editor for all things I type : whether that typing be email,
task management, mySQL statements or html/css/php. The benefits are
manyfold.

Someone told me recently that Emacs is much better for Java development
than Eclipse. That is stretching the meaning of the world "best" too far
IMO and some people who talk about Emacs competing with such need to try
it and not start the experiment moaning about emacs key bindings not
working ;)

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Richard Riley <rileyrg@googlemail.com> writes:
> But nearly all allow you to configure the tools they use to one extent or
> another. Eclipse is a VERY customisable IDE. The key is the word
> "integrated" however.

Indeed, it is the key.  I already mentionned, that emacs was an
IntegratING Development Environment, while the others were merely
IntegratED  Development Environments.  It's all the difference.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Richard Riley]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>> But nearly all allow you to configure the tools they use to one extent or
>> another. Eclipse is a VERY customisable IDE. The key is the word
>> "integrated" however.
>
> Indeed, it is the key.  I already mentionned, that emacs was an
> IntegratING Development Environment, while the others were merely
> IntegratED  Development Environments.  It's all the difference.

I honestly feel if cedet worked Emacs would get there. As it is, I gave
up on it. Too many unknowns - I was never sure if it was my config or
cedet which didnt work. That and the stuttering. It also needs better
mixed mode support (nxhtml does a great job meanwhile) and some
"official" direction for Java/Python would be nice : they are here to
stay no matter what one might think of them. Emacs is a programmers
editor ... 

But semantic and cedet working out of the box would be a great start :
with .h completion for things like c not being a "oh you want that, I
dont use it " but rather a "turned on by default". Class browsing in
Java an obvious must. Also a simple "turn on auto completion" using
something 3rd party like auto-complete and not another reinvented
wheel. As it is its simply too hard for most people to get working I
think : its the programming config equivalent of getting Gnus working;)

I really believe the more users then the more progress. As it is I see
people jumping ship faster than they are coming aboard. And that bodes
ill for the future.

Re: c/c++ project management and debugging

[Elena]

On Dec 23, 1:07 pm, Richard Riley <rile...@googlemail.com> wrote:
> Someone told me recently that Emacs is much better for Java development
> than Eclipse. That is stretching the meaning of the world "best" too far
> IMO and some people who talk about Emacs competing with such need to try
> it and not start the experiment moaning about emacs key bindings not
> working ;)

You got it.

Re: c/c++ project management and debugging

[rusi]

On Dec 23, 6:07 pm, Richard Riley <rile...@googlemail.com> wrote:
> Point of order : I refer to emacs as an IDE although many think its
> not. Its certainly very weak in these areas (out of the box or unless
> you're an elisp guru):-
>
> project management (cedet is simply too complex and it seems rarely used)
> dependency management (really part of above)
> code navigation (tags dont cut it and cedet is, well, complex)
> context help
> templates and smart parameters (inline code completions - and I dont
> mean a tab key murdering static template mechanism like yasnippet)
> context help
> mixed mode programming (php/html for example)
> java and Javascript
> Python (no one seems to know which way to go here)

+1

> I really believe the more users then the more progress. As it is I
> see people jumping ship faster than they are coming aboard. And that
> bodes ill for the future.

+1

Re: c/c++ project management and debugging

[Gary]

Richard Riley wrote:

> Eclipse is a VERY customisable IDE. The key is the word
> "integrated" however.

When used in connection with Eclipse, the I stands for "Incredibly
slow". I'd tell you what I think the D & E stand for as well, but it's
much less polite.

Re: c/c++ project management and debugging

[Gary]

Richard Riley wrote:
> Its certainly very weak in these areas (out of the box or unless
> you're an elisp guru):-
...
> templates and smart parameters (inline code completions - and I dont
> mean a tab key murdering static template mechanism like yasnippet)

I haven't used it for templates, if you mean stuff like C++ templates,
but I've found Tomohiro Matsuyama's auto-complete to be *very* good for
code completion.

...
> mixed mode programming (php/html for example)

nxhtml.

Re: c/c++ project management and debugging

[Richard Riley]

Gary <help-gnu-emacs@garydjones.name> writes:

> Richard Riley wrote:
>
>> Eclipse is a VERY customisable IDE. The key is the word
>> "integrated" however.
>
> When used in connection with Eclipse, the I stands for "Incredibly
> slow". I'd tell you what I think the D & E stand for as well, but it's
> much less polite.
>

Slow in what aspect?

Slow to load maybe (as all java apps are..). But everything else it does
it pretty lean mean when you consider what it does to - a lot.

Obviously you cant compare it to vi ...

Re: c/c++ project management and debugging

[Elena]

On Dec 24, 12:09 pm, Richard Riley <rile...@googlemail.com> wrote:
> Gary <help-gnu-em...@garydjones.name> writes:
> > Richard Riley wrote:
>
> >> Eclipse is a VERY customisable IDE. The key is the word
> >> "integrated" however.
>
> > When used in connection with Eclipse, the I stands for "Incredibly
> > slow". I'd tell you what I think the D & E stand for as well, but it's
> > much less polite.
>
> Slow in what aspect?
>
> Slow to load maybe (as all java apps are..). But everything else it does
> it pretty lean mean when you consider what it does to - a lot.
>
> Obviously you cant compare it to vi ...

I think "slow" in the sense that you sometimes have to wait for the
IDE to accomplish some heavy task, and having to wait makes you feel
the IDE is slow.  OTOH, developing software in Emacs makes you do a
lot of things by hand, thus keeping you busy while you are
accomplishing your goals, and that makes you feel the editor is snappy.

Re: c/c++ project management and debugging

[Gary]

Richard Riley wrote:
> Gary writes:
>
>> Richard Riley wrote:
>>
>>> Eclipse is a VERY customisable IDE. The key is the word
>>> "integrated" however.
>>
>> When used in connection with Eclipse, the I stands for "Incredibly
>> slow".

> Slow in what aspect?

You know, I choose to block out the horror so don't remember any
more. http://www.google.com/search?hl=en&q=eclipse+slow does return nine
million results though, so I think it wasn't my imagination.

Re: c/c++ project management and debugging

[Richard Riley]

Gary <help-gnu-emacs@garydjones.name> writes:

> Richard Riley wrote:
>> Gary writes:
>>
>>> Richard Riley wrote:
>>>
>>>> Eclipse is a VERY customisable IDE. The key is the word
>>>> "integrated" however.
>>>
>>> When used in connection with Eclipse, the I stands for "Incredibly
>>> slow".
>
>> Slow in what aspect?
>
> You know, I choose to block out the horror so don't remember any
> more. http://www.google.com/search?hl=en&q=eclipse+slow does return nine
> million results though, so I think it wasn't my imagination.
>

I'm no eclipse fan but I dont recall it being slow in anything other
than start up : typical for a Java app but on a modern machine the
facilities it brings to programming with complex class hierarchies
certainly offsets that. Emacs cant come close to it for many commonplace
requirements these days (I wont list them again and am aware most Emacs
users, myself included,  dont really need or want these things).

Re: c/c++ project management and debugging

[Gary]

Richard Riley wrote:
> I'm no eclipse fan but I dont recall it being slow in anything other
> than start up : typical for a Java app but on a modern machine the
> facilities it brings to programming with complex class hierarchies
> certainly offsets that. Emacs cant come close to it for many commonplace
> requirements these days (I wont list them again and am aware most Emacs
> users, myself included,  dont really need or want these things).

Thankfully I don't do any Java work these days, so I don't need or want
Eclipse, either :) Actually, come to that, I don't think I ever *wanted*
it..

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Richard Riley <rileyrg@googlemail.com> writes:

> I'm no eclipse fan but I dont recall it being slow in anything other
> than start up : typical for a Java app but on a modern machine the
> facilities it brings to programming with complex class hierarchies
> certainly offsets that. Emacs cant come close to it for many commonplace
> requirements these days (I wont list them again and am aware most Emacs
> users, myself included,  dont really need or want these things).

Indeed.  The problem might not be eclipse, but the need for eclipse.

http://groups.google.com/group/comp.lang.lisp/msg/fc76ebab1cb2f863


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Richard Riley]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> I'm no eclipse fan but I dont recall it being slow in anything other
>> than start up : typical for a Java app but on a modern machine the
>> facilities it brings to programming with complex class hierarchies
>> certainly offsets that. Emacs cant come close to it for many commonplace
>> requirements these days (I wont list them again and am aware most Emacs
>> users, myself included,  dont really need or want these things).
>
> Indeed.  The problem might not be eclipse, but the need for eclipse.
>
> http://groups.google.com/group/comp.lang.lisp/msg/fc76ebab1cb2f863

It's frequently the case that people who dont have something spend a lot
of time explaining why they think they dont need it or, and worse,
telling others why they dont need something. Only later when they get it
do they realise they had been slightly intransigent and possibly even
closed minded : I know I pooh poohed eclipse for ages until I saw what
it could do. It's always worth considering why something exists :
invariably because people wanted and needed it.

All that said, as I mentioned before, the benefits of Emacs overrides
the benefits of Eclipse in most cases - for me. And thats because I live
in org-mode and gnus pretty much. And erc... and ....

Re: c/c++ project management and debugging

[Le Wang]

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

Years ago, when I used eclipse, I thought it was slow, but quite a
reasonable IDE.  Years ago, I thought Emacs was slow too.  Computers got a
whole lot faster.

My opinion of Eclipse aside, generally, when someone argues <noun> is
<adjective> because Google results count is xxx, you should seriously
question that side of the argument.

For what it's worth, Eclipse+fast gets me 24 million results.  So that's
what?  2.5 times more reliable than Eclipse+slow?

On Mon, Jan 10, 2011 at 9:49 PM, Richard Riley <rileyrg@googlemail.com>wrote:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
> > Richard Riley <rileyrg@googlemail.com> writes:
> >
> >> I'm no eclipse fan but I dont recall it being slow in anything other
> >> than start up : typical for a Java app but on a modern machine the
> >> facilities it brings to programming with complex class hierarchies
> >> certainly offsets that. Emacs cant come close to it for many commonplace
> >> requirements these days (I wont list them again and am aware most Emacs
> >> users, myself included,  dont really need or want these things).
> >
> > Indeed.  The problem might not be eclipse, but the need for eclipse.
> >
> > http://groups.google.com/group/comp.lang.lisp/msg/fc76ebab1cb2f863
>
> It's frequently the case that people who dont have something spend a lot
> of time explaining why they think they dont need it or, and worse,
> telling others why they dont need something. Only later when they get it
> do they realise they had been slightly intransigent and possibly even
> closed minded : I know I pooh poohed eclipse for ages until I saw what
> it could do. It's always worth considering why something exists :
> invariably because people wanted and needed it.
>
> All that said, as I mentioned before, the benefits of Emacs overrides
> the benefits of Eclipse in most cases - for me. And thats because I live
> in org-mode and gnus pretty much. And erc... and ....
>
>
>
>
>
>


-- 
Le

[-- Attachment #2: Type: text/html, Size: 2696 bytes --]

Re: c/c++ project management and debugging

[Gary]

Le Wang wrote:

> My opinion of Eclipse aside, generally, when someone argues <noun> is
> <adjective> because Google results count is xxx, you should seriously
> question
> that side of the argument.

I didn't claim it was slow "because Google results count is xxx", I
claimed that it was slow because that was my experience. Stop trying to
put words in my "mouth".

Re: c/c++ project management and debugging

[Richard Riley]

Gary <help-gnu-emacs@garydjones.name> writes:

> Le Wang wrote:
>
>> My opinion of Eclipse aside, generally, when someone argues <noun> is
>> <adjective> because Google results count is xxx, you should seriously
>> question
>> that side of the argument.
>
> I didn't claim it was slow "because Google results count is xxx", I
> claimed that it was slow because that was my experience. Stop trying to
> put words in my "mouth".
>

Eclipse isn't slow when using it. Well, not really any appreciable
amount slower than any other dekstop GUI editor. And its certainly a lot
more powerful than most if you are a programmer dealing with multiple
languages or wanting a common look and feel IDE for all projects. Mixed
mode in debian is kind of ok with nxhtml, but Java is nigh on impossible
(well, hard work - what is the status with JDEE now?), python is a
confusing mess (multiple python modes floating around) : of course the
benefits of Eclipse also introduce some overheads but not ones I feel
are detrimental to any development process.

Re: c/c++ project management and debugging

[Gary]

Richard Riley wrote:
> Gary writes:
>> Le Wang wrote:
>>
>>> My opinion of Eclipse aside, generally, when someone argues <noun> is
>>> <adjective> because Google results count is xxx, you should seriously
>>> question
>>> that side of the argument.
>>
>> I didn't claim it was slow "because Google results count is xxx", I
>> claimed that it was slow because that was my experience. Stop trying
> to
>> put words in my "mouth".
>>
>
> Eclipse isn't slow when using it. Well, not really any appreciable
> amount slower than any other dekstop GUI editor.

Sorry, but I disagree.

Re: c/c++ project management and debugging

[Andreas Röhler]

Am 10.01.2011 17:18, schrieb Richard Riley:
> Gary<help-gnu-emacs@garydjones.name>  writes:
>
>> Le Wang wrote:
>>
>>> My opinion of Eclipse aside, generally, when someone argues<noun>  is
>>> <adjective>  because Google results count is xxx, you should seriously
>>> question
>>> that side of the argument.
>>
>> I didn't claim it was slow "because Google results count is xxx", I
>> claimed that it was slow because that was my experience. Stop trying to
>> put words in my "mouth".
>>
>
> Eclipse isn't slow when using it. Well, not really any appreciable
> amount slower than any other dekstop GUI editor. And its certainly a lot
> more powerful than most if you are a programmer dealing with multiple
> languages or wanting a common look and feel IDE for all projects. Mixed
> mode in debian is kind of ok with nxhtml, but Java is nigh on impossible
> (well, hard work - what is the status with JDEE now?), python is a
> confusing mess (multiple python modes floating around)

Hi Richard,

can't contradict basically, but let me say: python-mode.el
at https://launchpad.net/python-mode

got some momentum.

What about joining the team?
In case you join, I'll propose a milestone "python auto-completion-mode"
during next weeks.

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/




  : of course the
> benefits of Eclipse also introduce some overheads but not ones I feel
> are detrimental to any development process.
>

Re: c/c++ project management and debugging

[rusi]

On Jan 11, 9:55 pm, Andreas Röhler <andreas.roeh...@easy-emacs.de>
wrote:
> Am 10.01.2011 17:18, schrieb Richard Riley:
>
>
>
> > Gary<help-gnu-em...@garydjones.name>  writes:
>
> >> Le Wang wrote:
>
> >>> My opinion of Eclipse aside, generally, when someone argues<noun>  is
> >>> <adjective>  because Google results count is xxx, you should seriously
> >>> question
> >>> that side of the argument.
>
> >> I didn't claim it was slow "because Google results count is xxx", I
> >> claimed that it was slow because that was my experience. Stop trying to
> >> put words in my "mouth".
>
> > Eclipse isn't slow when using it. Well, not really any appreciable
> > amount slower than any other dekstop GUI editor. And its certainly a lot
> > more powerful than most if you are a programmer dealing with multiple
> > languages or wanting a common look and feel IDE for all projects. Mixed
> > mode in debian is kind of ok with nxhtml, but Java is nigh on impossible
> > (well, hard work - what is the status with JDEE now?), python is a
> > confusing mess (multiple python modes floating around)
>
> Hi Richard,
>
> can't contradict basically, but let me say: python-mode.el
> athttps://launchpad.net/python-mode
>
> got some momentum.
Well thats good to know. The last I knew it was not working with
python3 (which means the latest python)
>
> What about joining the team?

I did send in a one-line patch https://bugs.launchpad.net/python-mode/+bug/450552
.....

> In case you join, I'll propose a milestone "python auto-completion-mode"
> during next weeks.
>
> Cheers

Re: c/c++ project management and debugging

[Richard Riley]

Le Wang <l26wang@gmail.com> writes:

> Years ago, when I used eclipse, I thought it was slow, but quite a
> reasonable IDE.  Years ago, I thought Emacs was slow too.  Computers
> got a whole lot faster.
>
> My opinion of Eclipse aside, generally, when someone argues <noun> is
> <adjective> because Google results count is xxx, you should seriously
> question that side of the argument.
>
> For what it's worth, Eclipse+fast gets me 24 million results.  So
> that's what?  2.5 times more reliable than Eclipse+slow?

Yup. I got to agree with that. Then go and google people asking about
smart code completion in Emacs and the time proven "non answer" of "have
you tried tags" or "I dont need context help or context API help"
.... ;) CEDET might be the future.

Re: c/c++ project management and debugging

[Richard Riley]

Gary <help-gnu-emacs@garydjones.name> writes:

> Richard Riley wrote:
>> Its certainly very weak in these areas (out of the box or unless
>> you're an elisp guru):-
> ...
>> templates and smart parameters (inline code completions - and I dont
>> mean a tab key murdering static template mechanism like yasnippet)
>
> I haven't used it for templates, if you mean stuff like C++ templates,
> but I've found Tomohiro Matsuyama's auto-complete to be *very* good for
> code completion.

I use auto-complete. But it doesnt do code completion in the true sense
of it without the semantic plugin and then its hit and miss.

It does word completion well enough eg from dictionaries, words in
buffers etc. But not smart code completion : thats an entirely
different thing.

A lot of people here have said they dont want or need it. I and many
others, having used it in things like eclipse, find it very useful. Its
almost a must have in these days of HUGE class hierarchies from Java or
even PHP libraries : remember you're not just getting variable and
method completion  - you are also getting parameter templates, context
help and the like.

Re: c/c++ project management and debugging

[Richard Riley]

Gary <help-gnu-emacs@garydjones.name> writes:

>
> ...
>> mixed mode programming (php/html for example)
>
> nxhtml.
>

Yes. I mentioned nxhtml earlier.

I've used nxhtml for quite a while and its good and has improved a lot
over recent years - kudos to Lennart for that. It's also pretty slow
and doesnt do things like javascript afaik - I'll gladly be corrected on
that one!

Remember I am not damning Emacs here. I'm just pointing out where it
lacks in comparison to some more "modern" alternatives. It's strengths
outweigh its weaknesses for me so I stick with it.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>
> That's what I was talking about: makefiles are akin to assembly
> language, with shell commands being the corresponding machine-
> language.  You should be "compiling" an higher-level language (that
> is, a language which understands projects: CMake, etc.) to makefiles.
>

Never said you shouldn't, but you'd better understand at least how those
higher level things work, otherwise you're just playing with black
boxes.

> That's the problem: every Emacs power user seems to be chasing this
> holy grail of a greatly customized Emacs, but I have yet to see a
> customized Emacs matching a customized IDE.

I've never seen instead an IDE which doesn't suck/eat all my memory for
doing nothing/is bloated of useless things and I never find what I
really need, but that's maybe my problem :D
>
> That's their fault, not their IDE's.  Comparing an heavily customized
> Emacs to a vanilla IDE is not fair.  Moreover, I can edit the same
> source file both in Emacs and Visual Studio, and each side is just an
> hot-key away.  I use each tool for its intended purpose: the text-
> editor (Emacs) to edit text, the code-editor (IDE) to edit code.

If you know enough elisp and bash scripting I really don't see what an
IDE can do better (apart from maybe for java).

Do you have things like
yasnippet/auto-complete/flyspell-prog-mode/org-mode on your wonderful
IDE?

Any IDE is not easy to customize and work better for some languages
only, I really don't see any advantage in using them.

I remember when I tried to have a better color theme on eclipse, there
is NO support for that, you have to substitute some files with some
xml-like syntax with other files.

This was only the first annoying thing I found before I closed it
(hopefully) forever...

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> Elena <egarrulo@gmail.com> writes:
>
>>
>> Oh, and makefiles are so old-school.  Upgrade yourself to something
>> more modern an IDE-friendly.
>
> What are you talking about, old-school :D?
>
> Plain makefiles maybe because they're not easily portable, 
 
I object.  Case:  the makefile of kermit.  It doesn't need autoconf, it
just works out of the box on the hundred of systems where kermit can be
compiled.  It can be compiled and run on more systems than any IDE could
ever be.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Rajinder Yadav]

On Tue, Dec 21, 2010 at 8:10 AM, Elena <egarrulo@gmail.com> wrote:
> On Dec 21, 12:00 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
>> i've never had the need to create a makefile or edit one by hand when i
>> code using visualstudio, all i care about is coding my project in C++
>> and getting on with life.
>
> You don't know what a professional IDE is then, and why Emacs isn't up
> to the task.

yes i do, you missed my point

> If you are doing professional C++ development, then you are tweaking
> your project settings all the time.  The VC++ Project Settings dialog
> is just a wrapper on top of a "Makefile" kind-of generator.  What VC++
> does that Emacs doesn't is setting default values which work unless
> you have special requirements.  That's why you felt that all you had
> to care about was coding your project in C++.  Development in Emacs
> does not give such luxury.
>
>> i love ruby on rails hacking, i love doing everything from the command
>> line, it's more faster and efficient coding a rails app when compared to
>> doing it with netbeans + ide, or whatever IDE is out there!
>
> Obviously, for hobbyists, an IDE is overkill.

you're saying ruby on rails is for hobbyists? btw, ide is not an
overkill, it's just you don't need an ide because rails comes with
tools like rake and generators that frankly is faster doing thing at
the command line with a simple text editor and terminal, reason i
choose emacs to code ruby on rails stuff, i started off with IDE like
netbeans but it just didn't feel right (for me, for others it's the
right choice)

> I'd really like this madness of recommending Emacs as an IDE to stop.
> When programmers hadn't anything better than an editor and/or programs
> were simpler, that made sense.  It doesn't make sense anymore.

it's only madness to you, to me its just another choice, how is having
emacs generating a make file even a simple one to get you going a IDE?
now you don't seem to fully understand IDE then =)

rails generates & comes with rake files (like makefiles), its all
command line executed, i don't call rails a IDE, ask any rails hacker,
they won't call it madness either

> Again, this is not a fault of Emacs developers: they are not "selling"
> Emacs as an IDE,  over-enthusiastic user are doing that.  Such users
> are pushing Emacs way beyond what it can handle.
>

--
- Hide quoted text -
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1

Re: c/c++ project management and debugging

[Richard Riley]

Rajinder Yadav <devguy.ca@gmail.com> writes:

> On Tue, Dec 21, 2010 at 8:10 AM, Elena <egarrulo@gmail.com> wrote:
>> On Dec 21, 12:00 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
>>> i've never had the need to create a makefile or edit one by hand when i
>>> code using visualstudio, all i care about is coding my project in C++
>>> and getting on with life.
>>
>> You don't know what a professional IDE is then, and why Emacs isn't up
>> to the task.
>
> yes i do, you missed my point
>
>> If you are doing professional C++ development, then you are tweaking
>> your project settings all the time.  The VC++ Project Settings dialog
>> is just a wrapper on top of a "Makefile" kind-of generator.  What VC++
>> does that Emacs doesn't is setting default values which work unless
>> you have special requirements.  That's why you felt that all you had
>> to care about was coding your project in C++.  Development in Emacs
>> does not give such luxury.
>>
>>> i love ruby on rails hacking, i love doing everything from the command
>>> line, it's more faster and efficient coding a rails app when compared to
>>> doing it with netbeans + ide, or whatever IDE is out there!
>>
>> Obviously, for hobbyists, an IDE is overkill.
>
> you're saying ruby on rails is for hobbyists? btw, ide is not an
> overkill, it's just you don't need an ide because rails comes with
> tools like rake and generators that frankly is faster doing thing at
> the command line with a simple text editor and terminal, reason i
> choose emacs to code ruby on rails stuff, i started off with IDE like
> netbeans but it just didn't feel right (for me, for others it's the
> right choice)

Then the IDEs you have used have not been configured IDEs. Its almost
never quicker anymore at the command line in a properly configured
IDE. A lot of people claim it is : invariably those who have not used a
modern IDE. Those things you do at the command line can be hot keyed in
an IDE too. As for "not needing" - do you know what an IDE is? I
actually use emacs as one - weaknesses not withstanding - so I kind of
disagree with Elena about that. Development is a lot more than "coding
in a text editor". Lets see what the IDE brings (and most of what Emacs
can do already and marked appropriately in brackets below):-

Dependency management (poor since I cant get cedet working and dont want
to learn another "project" framework such as EDE)
Context help for all parts of project development. (poor/non existent).
Standardised UI (excellent)
Error code navigation and cross referencing (not bad in Emacs when
compiling in emacs)
Bug tracking (Hmm I use org-mode)
Task prioritisation (org-mode)
Code navigation (awful. Tags are not up to the task for the most part).
Code refactoring (none afaik)
Version management (excellent with Magit).

Emacs is almost there I think. And with what it brings elsewhere I dont
feel I need an IDE - except for Java. Emacs java support is awful from
what I can see.

Re: c/c++ project management and debugging

[Rajinder Yadav]

On Tue, Dec 21, 2010 at 9:52 AM, Richard Riley <rileyrg@googlemail.com> wrote:
> Rajinder Yadav <devguy.ca@gmail.com> writes:
>
>> On Tue, Dec 21, 2010 at 8:10 AM, Elena <egarrulo@gmail.com> wrote:
>>> On Dec 21, 12:00 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
>>>> i've never had the need to create a makefile or edit one by hand when i
>>>> code using visualstudio, all i care about is coding my project in C++
>>>> and getting on with life.
>>>
>>> You don't know what a professional IDE is then, and why Emacs isn't up
>>> to the task.
>>
>> yes i do, you missed my point
>>
>>> If you are doing professional C++ development, then you are tweaking
>>> your project settings all the time.  The VC++ Project Settings dialog
>>> is just a wrapper on top of a "Makefile" kind-of generator.  What VC++
>>> does that Emacs doesn't is setting default values which work unless
>>> you have special requirements.  That's why you felt that all you had
>>> to care about was coding your project in C++.  Development in Emacs
>>> does not give such luxury.
>>>
>>>> i love ruby on rails hacking, i love doing everything from the command
>>>> line, it's more faster and efficient coding a rails app when compared to
>>>> doing it with netbeans + ide, or whatever IDE is out there!
>>>
>>> Obviously, for hobbyists, an IDE is overkill.
>>
>> you're saying ruby on rails is for hobbyists? btw, ide is not an
>> overkill, it's just you don't need an ide because rails comes with
>> tools like rake and generators that frankly is faster doing thing at
>> the command line with a simple text editor and terminal, reason i
>> choose emacs to code ruby on rails stuff, i started off with IDE like
>> netbeans but it just didn't feel right (for me, for others it's the
>> right choice)
>
> Then the IDEs you have used have not been configured IDEs. Its almost
> never quicker anymore at the command line in a properly configured
> IDE. A lot of people claim it is : invariably those who have not used a
> modern IDE. Those things you do at the command line can be hot keyed in
> an IDE too. As for "not needing" - do you know what an IDE is? I
> actually use emacs as one - weaknesses not withstanding - so I kind of
> disagree with Elena about that. Development is a lot more than "coding
> in a text editor". Lets see what the IDE brings (and most of what Emacs
> can do already and marked appropriately in brackets below):-

in the case of rails coding, you can easily get by with the command line

i can type,

rails g model post name:string ...

faster than I can click on a menu, open a dialog, then click on each
field and type in stuff, click on the ok(generate) button to generate
a model + boiler-code.

pretty much most of the rails development in done this way. it follows
conventions over configuration (you're not editing makefiles, etc),
suffice to say you don't need an IDE for rails coding and anyone will
be faster with the command + basic editor than with a IDE setup for
rails.

for C/C++ stuff, it's a different story, I would like the aid of an
IDE for project management, project dependencies, code browsing,
debugging and building executable or libraries.

> Dependency management (poor since I cant get cedet working and dont want
> to learn another "project" framework such as EDE)
> Context help for all parts of project development. (poor/non existent).
> Standardised UI (excellent)
> Error code navigation and cross referencing (not bad in Emacs when
> compiling in emacs)
> Bug tracking (Hmm I use org-mode)
> Task prioritisation (org-mode)
> Code navigation (awful. Tags are not up to the task for the most part).
> Code refactoring (none afaik)
> Version management (excellent with Magit).

excellent points, magit is cool, but i still use git from the command line =)

> Emacs is almost there I think. And with what it brings elsewhere I dont
> feel I need an IDE - except for Java. Emacs java support is awful from
> what I can see.
>

-- 
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 5:42 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 9:52 AM, Richard Riley <rile...@googlemail.com> wrote:
> > Rajinder Yadav <devguy...@gmail.com> writes:
>
> >> On Tue, Dec 21, 2010 at 8:10 AM, Elena <egarr...@gmail.com> wrote:
> >>> On Dec 21, 12:00 pm, Rajinder Yadav <devguy...@gmail.com> wrote:
> >>>> i've never had the need to create a makefile or edit one by hand when i
> >>>> code using visualstudio, all i care about is coding my project in C++
> >>>> and getting on with life.
>
> >>> You don't know what a professional IDE is then, and why Emacs isn't up
> >>> to the task.
>
> >> yes i do, you missed my point
>
> >>> If you are doing professional C++ development, then you are tweaking
> >>> your project settings all the time.  The VC++ Project Settings dialog
> >>> is just a wrapper on top of a "Makefile" kind-of generator.  What VC++
> >>> does that Emacs doesn't is setting default values which work unless
> >>> you have special requirements.  That's why you felt that all you had
> >>> to care about was coding your project in C++.  Development in Emacs
> >>> does not give such luxury.
>
> >>>> i love ruby on rails hacking, i love doing everything from the command
> >>>> line, it's more faster and efficient coding a rails app when compared to
> >>>> doing it with netbeans + ide, or whatever IDE is out there!
>
> >>> Obviously, for hobbyists, an IDE is overkill.
>
> >> you're saying ruby on rails is for hobbyists? btw, ide is not an
> >> overkill, it's just you don't need an ide because rails comes with
> >> tools like rake and generators that frankly is faster doing thing at
> >> the command line with a simple text editor and terminal, reason i
> >> choose emacs to code ruby on rails stuff, i started off with IDE like
> >> netbeans but it just didn't feel right (for me, for others it's the
> >> right choice)
>
> > Then the IDEs you have used have not been configured IDEs. Its almost
> > never quicker anymore at the command line in a properly configured
> > IDE. A lot of people claim it is : invariably those who have not used a
> > modern IDE. Those things you do at the command line can be hot keyed in
> > an IDE too. As for "not needing" - do you know what an IDE is? I
> > actually use emacs as one - weaknesses not withstanding - so I kind of
> > disagree with Elena about that. Development is a lot more than "coding
> > in a text editor". Lets see what the IDE brings (and most of what Emacs
> > can do already and marked appropriately in brackets below):-
>
> in the case of rails coding, you can easily get by with the command line
>
> i can type,
>
> rails g model post name:string ...

This could be done in an IDE by means of an interactive macro, very
easy to code, without having to click anything.

>
> faster than I can click on a menu, open a dialog, then click on each
> field and type in stuff, click on the ok(generate) button to generate
> a model + boiler-code.

If an IDE does not allow to automate recurring tasks, or forces you to
use menus, it isn't a decent IDE: dump it.

>
> pretty much most of the rails development in done this way. it follows
> conventions over configuration (you're not editing makefiles, etc),
> suffice to say you don't need an IDE for rails coding and anyone will
> be faster with the command + basic editor than with a IDE setup for
> rails.

Because they lack a decent IDE, Rails coders have to resort to a basic
editor + command line.  That is not to say that IDEs aren't better.
They are not available, that's a different story.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Richard Riley <rileyrg@googlemail.com> writes:
> Then the IDEs you have used have not been configured IDEs. Its almost
> never quicker anymore at the command line in a properly configured
> IDE. A lot of people claim it is : invariably those who have not used a
> modern IDE. Those things you do at the command line can be hot keyed in
> an IDE too. As for "not needing" - do you know what an IDE is? I
> actually use emacs as one - weaknesses not withstanding - so I kind of
> disagree with Elena about that. Development is a lot more than "coding
> in a text editor". Lets see what the IDE brings (and most of what Emacs
> can do already and marked appropriately in brackets below):-
>
> Dependency management (poor since I cant get cedet working and dont want
> to learn another "project" framework such as EDE)
> Context help for all parts of project development. (poor/non existent).
> Standardised UI (excellent)
> Error code navigation and cross referencing (not bad in Emacs when
> compiling in emacs)
> Bug tracking (Hmm I use org-mode)
> Task prioritisation (org-mode)
> Code navigation (awful. Tags are not up to the task for the most part).
> Code refactoring (none afaik)
> Version management (excellent with Magit).
>
> Emacs is almost there I think. And with what it brings elsewhere I dont
> feel I need an IDE - except for Java. Emacs java support is awful from
> what I can see.


You forgot that the I in IDE doesn't only mean "Integrated" but also
"Integrating".  Almost all the IDE fail lamentably on this point, while
you can easily Integrate any tool in emacs.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 9:51 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Richard Riley <rile...@googlemail.com> writes:
> > Then the IDEs you have used have not been configured IDEs. Its almost
> > never quicker anymore at the command line in a properly configured
> > IDE. A lot of people claim it is : invariably those who have not used a
> > modern IDE. Those things you do at the command line can be hot keyed in
> > an IDE too. As for "not needing" - do you know what an IDE is? I
> > actually use emacs as one - weaknesses not withstanding - so I kind of
> > disagree with Elena about that. Development is a lot more than "coding
> > in a text editor". Lets see what the IDE brings (and most of what Emacs
> > can do already and marked appropriately in brackets below):-
>
> > Dependency management (poor since I cant get cedet working and dont want
> > to learn another "project" framework such as EDE)
> > Context help for all parts of project development. (poor/non existent).
> > Standardised UI (excellent)
> > Error code navigation and cross referencing (not bad in Emacs when
> > compiling in emacs)
> > Bug tracking (Hmm I use org-mode)
> > Task prioritisation (org-mode)
> > Code navigation (awful. Tags are not up to the task for the most part).
> > Code refactoring (none afaik)
> > Version management (excellent with Magit).
>
> > Emacs is almost there I think. And with what it brings elsewhere I dont
> > feel I need an IDE - except for Java. Emacs java support is awful from
> > what I can see.
>
> You forgot that the I in IDE doesn't only mean "Integrated" but also
> "Integrating".  Almost all the IDE fail lamentably on this point, while
> you can easily Integrate any tool in emacs.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/
> A bad day in () is better than a good day in {}.

I don't think so.  IDEs allow for integration of other tools.  As a
matter of fact, I've integrated Emacs in my IDE: one hot-key raises
Emacs at the same line and column of the buffer I'm editing.  You
really can't do better than that, because Emacs doesn't allow to
integrate itself in other tools.

What I think IDEs fail at lamentably is providing their facilities
*outside* their environment, but then I think that Emacs doesn't fare
much better.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 8:28 am, Elena <egarr...@gmail.com> wrote:
> On Dec 21, 9:51 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>
>
>
> > Richard Riley <rile...@googlemail.com> writes:
> > > Then the IDEs you have used have not been configured IDEs. Its almost
> > > never quicker anymore at the command line in a properly configured
> > > IDE. A lot of people claim it is : invariably those who have not used a
> > > modern IDE. Those things you do at the command line can be hot keyed in
> > > an IDE too. As for "not needing" - do you know what an IDE is? I
> > > actually use emacs as one - weaknesses not withstanding - so I kind of
> > > disagree with Elena about that. Development is a lot more than "coding
> > > in a text editor". Lets see what the IDE brings (and most of what Emacs
> > > can do already and marked appropriately in brackets below):-
>
> > > Dependency management (poor since I cant get cedet working and dont want
> > > to learn another "project" framework such as EDE)
> > > Context help for all parts of project development. (poor/non existent).
> > > Standardised UI (excellent)
> > > Error code navigation and cross referencing (not bad in Emacs when
> > > compiling in emacs)
> > > Bug tracking (Hmm I use org-mode)
> > > Task prioritisation (org-mode)
> > > Code navigation (awful. Tags are not up to the task for the most part).
> > > Code refactoring (none afaik)
> > > Version management (excellent with Magit).
>
> > > Emacs is almost there I think. And with what it brings elsewhere I dont
> > > feel I need an IDE - except for Java. Emacs java support is awful from
> > > what I can see.
>
> > You forgot that the I in IDE doesn't only mean "Integrated" but also
> > "Integrating".  Almost all the IDE fail lamentably on this point, while
> > you can easily Integrate any tool in emacs.
>
> > --
> > __Pascal Bourguignon__                    http://www.informatimago.com/
> > A bad day in () is better than a good day in {}.
>
> I don't think so.  IDEs allow for integration of other tools.  As a
> matter of fact, I've integrated Emacs in my IDE: one hot-key raises
> Emacs at the same line and column of the buffer I'm editing.  You
> really can't do better than that, because Emacs doesn't allow to
> integrate itself in other tools.
>
> What I think IDEs fail at lamentably is providing their facilities
> *outside* their environment, but then I think that Emacs doesn't fare
> much better.

Moreover, when your heavily customized Emacs start to "misbehave" what
can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
advanced debugging aid!  Come on, Pascal, IDEs have something to teach.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> Moreover, when your heavily customized Emacs start to "misbehave" what
> can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
> advanced debugging aid!  

Contrarily to IDEs, emacs has a true debugger, and a true REPL, and a
whole lisp development environment.

The fact that emacs is sometimes heavily customized says something very
bad about IDEs: they cannot be customized easily!


> Come on, Pascal, IDEs have something to teach.

Yes.  That they're to be flown away as fast as you can.

They should also recall to those who forgot it, that humans are persons
who process the verb.  Our brains are hard wired for speach, to listen,
to speak, and to read and write.  This is what distinguish us from
animals.

A graphical user interface letting you build "sentences" from icons may
be good and nice for chimps who lack the neurons to process the verb,
but for us it's easier to just talk or write.  (And if we must compare
the civilization and technological output, I'd say that it's way more
powerful too!).


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 9:48 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Elena <egarr...@gmail.com> writes:
> > Moreover, when your heavily customized Emacs start to "misbehave" what
> > can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
> > advanced debugging aid!  
>
> Contrarily to IDEs, emacs has a true debugger, and a true REPL, and a
> whole lisp development environment.

Pascal, talk is cheap, show me the debugger: my Emacs 23 hangs every
few seconds.  How can I fix it with the help of such wonderful tools?
"emacs -Q" followed by evaluating each sexp in my init file is not
allowed.

Where is your goddess now?  Have a nice day.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 10:06 am, Elena <egarr...@gmail.com> wrote:
> On Dec 22, 9:48 am, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>
> > Elena <egarr...@gmail.com> writes:
> > > Moreover, when your heavily customized Emacs start to "misbehave" what
> > > can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
> > > advanced debugging aid!  
>
> > Contrarily to IDEs, emacs has a true debugger, and a true REPL, and a
> > whole lisp development environment.
>
> Pascal, talk is cheap, show me the debugger: my Emacs 23 hangs every
> few seconds.  How can I fix it with the help of such wonderful tools?
> "emacs -Q" followed by evaluating each sexp in my init file is not
> allowed.
>
> Where is your goddess now?  Have a nice day.

Forgot to mention: neither "C-g" does break the hang nor the hang
happens whenever I issue some specific command.  Thus your debugger,
REPL and whole lisp development environment can't help.  You'd need a
powerful IDE to debug such intricate cases.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:
>
> Forgot to mention: neither "C-g" does break the hang nor the hang
> happens whenever I issue some specific command.  Thus your debugger,
> REPL and whole lisp development environment can't help.  You'd need a
> powerful IDE to debug such intricate cases.

Frankly that's just bullshit.
Do you think an IDE could help you to solve problems with Emacs?

If it hangs and there is something serious your IDE will crash as well.
If you really have so serious bugs (which version/os?) only a debugger
can help.

If the problems are caused by your customized configuration use the
bisect technique.

First evaluate half of the buffer and see if it works or not, and so on
recursively.
I guess it will take not more than 1 minute to understand where the
problem is.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> Elena <egarrulo@gmail.com> writes:
>>
>> Forgot to mention: neither "C-g" does break the hang nor the hang
>> happens whenever I issue some specific command.  Thus your debugger,
>> REPL and whole lisp development environment can't help.  You'd need a
>> powerful IDE to debug such intricate cases.
>
> Frankly that's just bullshit.
> Do you think an IDE could help you to solve problems with Emacs?
>
> If it hangs and there is something serious your IDE will crash as well.

And the IDE I have in mind would crash several times a day actually.
And not even on MS-Windows, but on Linux!


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

Andrea Crotti <andrea.crott...@gmail.com> writes:
> > Elena <egarr...@gmail.com> writes:
>
> >> Forgot to mention: neither "C-g" does break the hang nor the hang
> >> happens whenever I issue some specific command.  Thus your debugger,
> >> REPL and whole lisp development environment can't help.  You'd need a
> >> powerful IDE to debug such intricate cases.
>
> > Frankly that's just bullshit.
> > Do you think an IDE could help you to solve problems with Emacs?

Of course it would.  Tracing, profiling and similar tools are
available for languages which are more powerful than extension
languages.

>
> > If it hangs and there is something serious your IDE will crash as well.

And you would debug it inside the IDE too.  What environment do you
think Eclipse developers use to debug Eclipse and its plugins?

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> Andrea Crotti <andrea.crott...@gmail.com> writes:
>> > Elena <egarr...@gmail.com> writes:
>>
>> >> Forgot to mention: neither "C-g" does break the hang nor the hang
>> >> happens whenever I issue some specific command.  Thus your debugger,
>> >> REPL and whole lisp development environment can't help.  You'd need a
>> >> powerful IDE to debug such intricate cases.
>>
>> > Frankly that's just bullshit.
>> > Do you think an IDE could help you to solve problems with Emacs?
>
> Of course it would.  Tracing, profiling and similar tools are
> available for languages which are more powerful than extension
> languages.

They are REQUIRED to be able to work with languages that are LESS
powerful than lisp.


>> > If it hangs and there is something serious your IDE will crash as well.
>
> And you would debug it inside the IDE too.  What environment do you
> think Eclipse developers use to debug Eclipse and its plugins?

We also use emacs lisp to debug emacs lisp.

Now, I grant you that we have a problem, in that some of emacs has been
written in C, instead of lisp.  This is for historical and practical (at
the time) reasons: to help spreading emacs, it had to be available on
unix system, where lisp compilers weren't easily available.

Nowadays, there are more lisp compilers on linux than C compilers, so it
would be easy to rewrite emacs in lisp.  


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 1:32 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Elena <egarr...@gmail.com> writes:
> > Andrea Crotti <andrea.crott...@gmail.com> writes:
> >> > Elena <egarr...@gmail.com> writes:
>
> >> >> Forgot to mention: neither "C-g" does break the hang nor the hang
> >> >> happens whenever I issue some specific command.  Thus your debugger,
> >> >> REPL and whole lisp development environment can't help.  You'd need a
> >> >> powerful IDE to debug such intricate cases.
>
> >> > Frankly that's just bullshit.
> >> > Do you think an IDE could help you to solve problems with Emacs?
>
> > Of course it would.  Tracing, profiling and similar tools are
> > available for languages which are more powerful than extension
> > languages.
>
> They are REQUIRED to be able to work with languages that are LESS
> powerful than lisp.

This is not the case.  I have a problem which would be dead-easy to
spot by using a tracer and a profiler.  Emacs Lisp lacks the former,
and that's fine since it is an extension language, not a language to
develop complex applications.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>>
>> They are REQUIRED to be able to work with languages that are LESS
>> powerful than lisp.
>
> This is not the case.  I have a problem which would be dead-easy to
> spot by using a tracer and a profiler.  Emacs Lisp lacks the former,
> and that's fine since it is an extension language, not a language to
> develop complex applications.

Dead easy if you knew how your configuration works probably.
Try like this, comment out everything you don't fully understand in your
.emacs, and then try again )

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> On Dec 22, 1:32 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> Elena <egarr...@gmail.com> writes:
>> > Andrea Crotti <andrea.crott...@gmail.com> writes:
>> >> > Elena <egarr...@gmail.com> writes:
>>
>> >> >> Forgot to mention: neither "C-g" does break the hang nor the hang
>> >> >> happens whenever I issue some specific command.  Thus your debugger,
>> >> >> REPL and whole lisp development environment can't help.  You'd need a
>> >> >> powerful IDE to debug such intricate cases.
>>
>> >> > Frankly that's just bullshit.
>> >> > Do you think an IDE could help you to solve problems with Emacs?
>>
>> > Of course it would.  Tracing, profiling and similar tools are
>> > available for languages which are more powerful than extension
>> > languages.
>>
>> They are REQUIRED to be able to work with languages that are LESS
>> powerful than lisp.
>
> This is not the case.  I have a problem which would be dead-easy to
> spot by using a tracer and a profiler.  Emacs Lisp lacks the former,
> and that's fine since it is an extension language, not a language to
> develop complex applications.

emacs lisp is not an extension language.  It's a complete algorithmic
programming language, and it has all the tools that any other
programming language has.  I already mentionned the commands to trace
and to profile.  Complex applications have been developed in emacs lisp,
including spreadsheets, web browsers, irc clients, news and email
readers, database management applications, expert systems, money
management and accounting applications, calendar and time tracking
aapplications, dictionary browsers, shell and terminal emulators, games,
etc.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Helmut Eller]

* Elena [2010-12-22 12:38] writes:

> Andrea Crotti <andrea.crott...@gmail.com> writes:
>> > Elena <egarr...@gmail.com> writes:
>>
>> >> Forgot to mention: neither "C-g" does break the hang nor the hang
>> >> happens whenever I issue some specific command.  Thus your debugger,
>> >> REPL and whole lisp development environment can't help.  You'd need a
>> >> powerful IDE to debug such intricate cases.
>>
>> > Frankly that's just bullshit.
>> > Do you think an IDE could help you to solve problems with Emacs?
>
> Of course it would.  Tracing, profiling and similar tools are
> available for languages which are more powerful than extension
> languages.

So why haven't you fixed the bug yet by using the IDE?

Helmut

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 4:09 pm, Helmut Eller <eller.hel...@gmail.com> wrote:
> * Elena [2010-12-22 12:38] writes:
>
> > Andrea Crotti <andrea.crott...@gmail.com> writes:
> >> > Elena <egarr...@gmail.com> writes:
>
> >> >> Forgot to mention: neither "C-g" does break the hang nor the hang
> >> >> happens whenever I issue some specific command.  Thus your debugger,
> >> >> REPL and whole lisp development environment can't help.  You'd need a
> >> >> powerful IDE to debug such intricate cases.
>
> >> > Frankly that's just bullshit.
> >> > Do you think an IDE could help you to solve problems with Emacs?
>
> > Of course it would.  Tracing, profiling and similar tools are
> > available for languages which are more powerful than extension
> > languages.
>
> So why haven't you fixed the bug yet by using the IDE?

Because:
- the source tree of Emacs (understandably) does not support the tools
chain I know (Visual Studio), and:
- Emacs 22 hangs way less, thus just sticking to it is easier, and:
- running two different versions of Emacs on two different OSes has
been a nice lesson on portability.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> On Dec 22, 9:48 am, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> Elena <egarr...@gmail.com> writes:
>> > Moreover, when your heavily customized Emacs start to "misbehave" what
>> > can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
>> > advanced debugging aid!  
>>
>> Contrarily to IDEs, emacs has a true debugger, and a true REPL, and a
>> whole lisp development environment.
>
> Pascal, talk is cheap, show me the debugger: my Emacs 23 hangs every
> few seconds.  How can I fix it with the help of such wonderful tools?

If you experiment hangs up, then you should debug them with gdb, because
they're bugs in the virtual machine.

If you have bug in emacs, then the first thing to do is 
M-x set-variable RET debug-on-error RET t RET
so that any error breaks into the emacs lisp debugger.


> "emacs -Q" followed by evaluating each sexp in my init file is not
> allowed.
>
> Where is your goddess now?  Have a nice day.


This is not my experience.  What I observe, is that emacs has an uptime
only limited by the uptime of the underlying system.

M-! uptime RET
 11:21:56 up 4 days,  8:01, 14 users,  load average: 0.85, 0.83, 0.82
(uptime) C-x C-e
 "Up 4d 6h 58m 47s (Sat 2010-12-18 04:23:14), 56 buffers, 5 files"


ssh voyager.informatimago.com uptime
 11:17:47 up 79 days,  6:51,  0 users,  load average: 0.11, 0.03, 0.01
ssh voyager.informatimago.com emacsclient -e '\(uptime\)'
".EMACS: Up 70d 6h 47m 51s (Wed 2010-10-13 05:30:20), 8 buffers, 1 files"



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 10:25 am, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> Elena <egarr...@gmail.com> writes:
> > On Dec 22, 9:48 am, "Pascal J. Bourguignon" <p...@informatimago.com>
> > wrote:
> >> Elena <egarr...@gmail.com> writes:
> >> > Moreover, when your heavily customized Emacs start to "misbehave" what
> >> > can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
> >> > advanced debugging aid!  
>
> >> Contrarily to IDEs, emacs has a true debugger, and a true REPL, and a
> >> whole lisp development environment.
>
> > Pascal, talk is cheap, show me the debugger: my Emacs 23 hangs every
> > few seconds.  How can I fix it with the help of such wonderful tools?
>
> If you experiment hangs up, then you should debug them with gdb, because
> they're bugs in the virtual machine.

No need to bring in the bigger guns.  It could just be some scheduled
activity by who-knows what package.  If Emacs Lisp had both a tracing
and a profiling utility, I would have squashed the bug already.

> If you have bug in emacs, then the first thing to do is
> M-x set-variable RET debug-on-error RET t RET
> so that any error breaks into the emacs lisp debugger.

Oh, already done.  That's easy.  No error whatsoever.

>
> > "emacs -Q" followed by evaluating each sexp in my init file is not
> > allowed.
>
> > Where is your goddess now?  Have a nice day.
>
> This is not my experience.  What I observe, is that emacs has an uptime
> only limited by the uptime of the underlying system.

"emacs -Q" is effective in deciding whether something comes from
Emacs' default behavior or from some package.  Once you have decided
it must be some package, that's the hairy part where Emacs debugging
tools aren't up to the task.  That's why I have said that users have
pushed Emacs beyond its capabilities:  IDE, mail-reader... guys, here
we have just a simple text editor which doesn't pretend to by anything
else.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:
>
> No need to bring in the bigger guns.  It could just be some scheduled
> activity by who-knows what package.  If Emacs Lisp had both a tracing
> and a profiling utility, I would have squashed the bug already.

Never heard of packages scheduling activities, but I might be wrong.
You should know what external stuff you installed, try to disable some
stuff and see again.

And btw there tracing and debugging step by step works pretty well,
maybe it's just you not knowing how to use it.
(check the info page)

> "emacs -Q" is effective in deciding whether something comes from
> Emacs' default behavior or from some package.  Once you have decided
> it must be some package, that's the hairy part where Emacs debugging
> tools aren't up to the task.  That's why I have said that users have
> pushed Emacs beyond its capabilities:  IDE, mail-reader... guys, here
> we have just a simple text editor which doesn't pretend to by anything
> else.

Last time I had two reboot my machine emacs had an uptime of 55 days.
In those days I wrote thousands of lines of code, compiled, wrote mails
with gnus and basically did everything I need to do but twice as fast as
the IDE guys ;)

If you really think it's just a simple text editor then
- stop using it
- be happy with your wonderful IDE
- look for another simpler editor

If instead you would like to learn more try to be more constructive to
spot your problem and to solve future problems.

You should try to solve your problem, and when you get stuck, describe
the situation and send your questions to the list, I'm sure you'll solve
it quickly and learning something new.

But it should be clear that the implication
my Emacs hangs -> IDEs are better

it's completely nonsense, and rather ridicolous from my point of view.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> No need to bring in the bigger guns.  It could just be some scheduled
> activity by who-knows what package.  If Emacs Lisp had both a tracing
> and a profiling utility, I would have squashed the bug already.

It has.  trace-function and elp.


>> This is not my experience.  What I observe, is that emacs has an uptime
>> only limited by the uptime of the underlying system.
>
> "emacs -Q" is effective in deciding whether something comes from
> Emacs' default behavior or from some package.  Once you have decided
> it must be some package, that's the hairy part where Emacs debugging
> tools aren't up to the task.  

No, that's the easy part: you have all the sources available, you have
an embedded debugger, tracer, profiler, documentation, editor, a while
integrated lisp developping environment.

> That's why I have said that users have
> pushed Emacs beyond its capabilities:  IDE, mail-reader... guys, here
> we have just a simple text editor which doesn't pretend to by anything
> else.

No.  emacs is a lisp machine, and like any computer, you stack on it an
OS, a user interface, a shell, an editor, and all kinds of applications
and utilities.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 1:04 pm, Andrea Crotti <andrea.crott...@gmail.com> wrote:
> Elena <egarr...@gmail.com> writes:
>
> > No need to bring in the bigger guns.  It could just be some scheduled
> > activity by who-knows what package.  If Emacs Lisp had both a tracing
> > and a profiling utility, I would have squashed the bug already.
>
> Never heard of packages scheduling activities, but I might be wrong.
> You should know what external stuff you installed, try to disable some
> stuff and see again.

Same as: "emacs -Q" then eval sexp.  Only problem, my .emacs is more
than 200KB.  I would have liked to modularize it, but Emacs lacking of
IDE-like facilities to navigate Emacs Lisp made me give up that.

>
> And btw there tracing and debugging step by step works pretty well,
> maybe it's just you not knowing how to use it.
> (check the info page)

What I mean with "tracing":

http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Procedures-related-to-debugging

scroll till the section "trace".

Profiling still lacking, anyway.

>
> > "emacs -Q" is effective in deciding whether something comes from
> > Emacs' default behavior or from some package.  Once you have decided
> > it must be some package, that's the hairy part where Emacs debugging
> > tools aren't up to the task.  That's why I have said that users have
> > pushed Emacs beyond its capabilities:  IDE, mail-reader... guys, here
> > we have just a simple text editor which doesn't pretend to by anything
> > else.
>
> Last time I had two reboot my machine emacs had an uptime of 55 days.
> In those days I wrote thousands of lines of code, compiled, wrote mails
> with gnus and basically did everything I need to do but twice as fast as
> the IDE guys ;)

Just like me as long as I stay away from Emacs 23.x and stick to 22.3.

>
> If you really think it's just a simple text editor then
> - stop using it
> - be happy with your wonderful IDE
> - look for another simpler editor
>
> If instead you would like to learn more try to be more constructive to
> spot your problem and to solve future problems.
>
> You should try to solve your problem, and when you get stuck, describe
> the situation and send your questions to the list, I'm sure you'll solve
> it quickly and learning something new.

Done already.  Nobody has been able to help.  Currently Emacs lacks
needed tools.  I'm sticking to Emacs 22, which hangs much less.

I always try to be constructive in helping package maintainers to
track down bugs, but I'm not an advanced user.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>
> Same as: "emacs -Q" then eval sexp.  Only problem, my .emacs is more
> than 200KB.  I would have liked to modularize it, but Emacs lacking of
> IDE-like facilities to navigate Emacs Lisp made me give up that.

emacs doesn't lack that, you don't know how to use it ;)
C-h f and you can jump to any function you want.
The inline documentation and the ability to trace/try out/see the
implementation of all the elisp functions is wonderful.

With semantic in your elisp file you can jump easily to any
function/variable you want and so on.

And let me understand, your .emacs is more than 200KB but you're not ad
advanced user?
How can that be?

The only explanation is that you copied everything could sound nice
inside and now you have no idea of what could go wrong.
Well if that is the case first you should understand very well what's in
your .emacs.

Mine is only 57Kb after a couple of years of customizations.

> What I mean with "tracing":
>
> http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Procedures-related-to-debugging
>
> scroll till the section "trace".
>
> Profiling still lacking, anyway.
>

trace-function?
There are packages also for profiling, but I really don't think it could
help solve your problem since it gets completely stuck (not just slow).

> Done already.  Nobody has been able to help.  Currently Emacs lacks
> needed tools.  I'm sticking to Emacs 22, which hangs much less.
>
> I always try to be constructive in helping package maintainers to
> track down bugs, but I'm not an advanced user.

I think instead you lack needed knowledge instead, otherwise how do you
think that the developers are able to do a wonderful work without those tools?

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 2:12 pm, Andrea Crotti <andrea.crott...@gmail.com> wrote:
> Elena <egarr...@gmail.com> writes:
>
> > Same as: "emacs -Q" then eval sexp.  Only problem, my .emacs is more
> > than 200KB.  I would have liked to modularize it, but Emacs lacking of
> > IDE-like facilities to navigate Emacs Lisp made me give up that.
>
> emacs doesn't lack that, you don't know how to use it ;)
> C-h f and you can jump to any function you want.
> The inline documentation and the ability to trace/try out/see the
> implementation of all the elisp functions is wonderful.
>
> With semantic in your elisp file you can jump easily to any
> function/variable you want and so on.
>
> And let me understand, your .emacs is more than 200KB but you're not ad
> advanced user?
> How can that be?
>
> The only explanation is that you copied everything could sound nice
> inside and now you have no idea of what could go wrong.
> Well if that is the case first you should understand very well what's in
> your .emacs.

More or less.  When I started learning Emacs, I began copying snippets
of code without really understanding how they worked.  Nowadays, I
still have a difficult time understanding some of them.  I've become
used to the facilities they provide, therefore my refactoring is a bit
at a time.  Not all of such code gets evaluated, though.

>
> Mine is only 57Kb after a couple of years of customizations.
>
> > What I mean with "tracing":
>
> >http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Procedures-rela...
>
> > scroll till the section "trace".
>
> > Profiling still lacking, anyway.
>
> trace-function?
> There are packages also for profiling, but I really don't think it could
> help solve your problem since it gets completely stuck (not just slow).

You are right about profiling: packages do exist which do a fine job.

Regarding tracing, I failed to explain, sorry.  I didn't mean such
kind of trace.  I was thinking about a logging facility, which logged
calls outside user control.  Such a facility, together with a profiler
and a call-tree generator, would have made easy tracking down the
function (or functions) which were causing the hang.

>
> > Done already.  Nobody has been able to help.  Currently Emacs lacks
> > needed tools.  I'm sticking to Emacs 22, which hangs much less.
>
> > I always try to be constructive in helping package maintainers to
> > track down bugs, but I'm not an advanced user.
>
> I think instead you lack needed knowledge instead, otherwise how do you
> think that the developers are able to do a wonderful work without those tools?

Nope.  I have submitted here the issue to experienced Emacs users and
they have not been able to help.  Thus it is not a matter of lack of
knowledge, it's just the lack of tools.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>>
>> I think instead you lack needed knowledge instead, otherwise how do you
>> think that the developers are able to do a wonderful work without those tools?
>
> Nope.  I have submitted here the issue to experienced Emacs users and
> they have not been able to help.  Thus it is not a matter of lack of
> knowledge, it's just the lack of tools.

Yes of course, but I would bet 1000€ that if you give your computer to
an emacs guru (which has nothing better to do :D) in 5 minutes it will
spot and solve the problem, even with such a "poor" environment.

Re: c/c++ project management and debugging

[Elena]

On Dec 22, 1:04 pm, Andrea Crotti <andrea.crott...@gmail.com> wrote:
> Elena <egarr...@gmail.com> writes:
>
> > No need to bring in the bigger guns.  It could just be some scheduled
> > activity by who-knows what package.  If Emacs Lisp had both a tracing
> > and a profiling utility, I would have squashed the bug already.
>
> Never heard of packages scheduling activities, but I might be wrong.

Think about auto-saving facilities and such.

> But it should be clear that the implication
> my Emacs hangs -> IDEs are better
>
> it's completely nonsense, and rather ridicolous from my point of view.

Indeed it is, and in fact I've not said that.  I've said:

IDEs are more effective than editors for software development ->
Emacs ships as an editor, not as an IDE ->
Building an IDE on top of Emacs is a time-consuming and wheel-
reinventing task ->
Thuse: use an IDE, and effortlessly switch back and forth it and Emacs
if you like.

I don't understand why some Emacs users seem to think that every other
program can be a tool to Emacs, whilst using Emacs as a tool of a more
comprehensive environment is "blasphemy".

Re: c/c++ project management and debugging

[Eli Zaretskii]

> From: Elena <egarrulo@gmail.com>
> Newsgroups: gnu.emacs.help
> Date: Thu, 23 Dec 2010 04:35:39 -0800 (PST)
> 
> I don't understand why some Emacs users seem to think that every other
> program can be a tool to Emacs, whilst using Emacs as a tool of a more
> comprehensive environment is "blasphemy".

Because Emacs is The Way Of Life, and there can be only one way of
living your life.  If you don't understand that, then you are not
(yet) ready to come into the congregation of True Emacs Believers.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>
> Indeed it is, and in fact I've not said that.  I've said:
>
> IDEs are more effective than editors for software development ->
> Emacs ships as an editor, not as an IDE ->
> Building an IDE on top of Emacs is a time-consuming and wheel-
> reinventing task ->
> Thuse: use an IDE, and effortlessly switch back and forth it and Emacs
> if you like.
>
> I don't understand why some Emacs users seem to think that every other
> program can be a tool to Emacs, whilst using Emacs as a tool of a more
> comprehensive environment is "blasphemy".

- It ships by default with org-mode/calc/games and another thousand
  things that are not normally in one text editor, who told you it was
  shipping as an editor?

- the time consumed is not yours anyway and for many people is very
  useful. The fact that all the other IDE stinks is of course a plus ;)

- of course, switching back and forth on different programs is veeeeeery
  productive ;)

Re: c/c++ project management and debugging

[Richard Riley]

Andrea Crotti <andrea.crotti.0@gmail.com> writes:

> Elena <egarrulo@gmail.com> writes:
>
>>
>> Indeed it is, and in fact I've not said that.  I've said:
>>
>> IDEs are more effective than editors for software development ->
>> Emacs ships as an editor, not as an IDE ->
>> Building an IDE on top of Emacs is a time-consuming and wheel-
>> reinventing task ->
>> Thuse: use an IDE, and effortlessly switch back and forth it and Emacs
>> if you like.
>>
>> I don't understand why some Emacs users seem to think that every other
>> program can be a tool to Emacs, whilst using Emacs as a tool of a more
>> comprehensive environment is "blasphemy".
>
> - It ships by default with org-mode/calc/games and another thousand
>   things that are not normally in one text editor, who told you it was
>   shipping as an editor?

Because it IS an editor...

>
> - the time consumed is not yours anyway and for many people is very
>   useful. The fact that all the other IDE stinks is of course a plus
>   ;)

Except they don't. What ones have you used and how do you compare the
programming features they have, which have been listed, to those that
emacs provides? Remember we are talking about the *development* features
: not the text manipulation features which is obviously an area in which
emacs excels.

>
> - of course, switching back and forth on different programs is veeeeeery
>   productive ;)
>

What different programs? IDE. "Integrated" development
environment. code, compile, debug, recycle. And all designed to work in
harmony. 

This is starting to sound like me not liking emacs and that is not the
case. But uninformed opinions about modern IDEs are pretty worthless
when trying to compare Emacs to the features they provide and possibly
suggest easy reach Emacs improvements which will greatly increase its
attraction to new users.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Richard Riley <rileyrg@googlemail.com> writes:

>> - It ships by default with org-mode/calc/games and another thousand
>>   things that are not normally in one text editor, who told you it was
>>   shipping as an editor?
>
> Because it IS an editor...

Not exactly.  It has been sold as such, I'll admit that, but there's
nothing in emacs that makes the process data type less fundamental than
the buffer data type in emacs.  Or any other data type, used by one of
the innumerous applications written in emacs lisp.

The editor is just one such application, but it has nothing special.


> What different programs? IDE. "Integrated" development
> environment. code, compile, debug, recycle. And all designed to work in
> harmony. 

Well, yes, code, compile, debug, recycle.  When you program in lisp (or
one of the newer programming languages so much inspired by lisp it's a
shame), you don't do that.


> This is starting to sound like me not liking emacs and that is not the
> case. But uninformed opinions about modern IDEs are pretty worthless
> when trying to compare Emacs to the features they provide and possibly
> suggest easy reach Emacs improvements which will greatly increase its
> attraction to new users.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Richard Riley]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>>> - It ships by default with org-mode/calc/games and another thousand
>>>   things that are not normally in one text editor, who told you it was
>>>   shipping as an editor?
>>
>> Because it IS an editor...
>
> Not exactly.  It has been sold as such, I'll admit that, but there's
> nothing in emacs that makes the process data type less fundamental than
> the buffer data type in emacs.  Or any other data type, used by one of
> the innumerous applications written in emacs lisp.
>
> The editor is just one such application, but it has nothing special.

It is an editor .. ;) It is other things besides...

>
>> What different programs? IDE. "Integrated" development
>> environment. code, compile, debug, recycle. And all designed to work in
>> harmony. 
>
> Well, yes, code, compile, debug, recycle.  When you program in lisp (or
> one of the newer programming languages so much inspired by lisp it's a
> shame), you don't do that.

I do a little elisp. And obviously emacs is a "nice IDE" for that.

>
>> This is starting to sound like me not liking emacs and that is not the
>> case. But uninformed opinions about modern IDEs are pretty worthless
>> when trying to compare Emacs to the features they provide and possibly
>> suggest easy reach Emacs improvements which will greatly increase its
>> attraction to new users.

Re: c/c++ project management and debugging

[rusi]

On Dec 24, 7:18 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
>
> Well, yes, code, compile, debug, recycle.  When you program in lisp (or
> one of the newer programming languages so much inspired by lisp it's a
> shame), you don't do that.

Just curious Pascal: Is it a 'shame' because they are inspired but not
enough or is it because the imitation is so good its better than the
original?

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

rusi <rustompmody@gmail.com> writes:

> On Dec 24, 7:18 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>>
>> Well, yes, code, compile, debug, recycle.  When you program in lisp (or
>> one of the newer programming languages so much inspired by lisp it's a
>> shame), you don't do that.
>
> Just curious Pascal: Is it a 'shame' because they are inspired but not
> enough or is it because the imitation is so good its better than the
> original?

The former.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[Andrea Crotti]

Elena <egarrulo@gmail.com> writes:

>
> Moreover, when your heavily customized Emacs start to "misbehave" what
> can you do?  Start "emacs -Q" and begin evaluating sexps.  Oh, what an
> advanced debugging aid!  Come on, Pascal, IDEs have something to teach.

That doesn't make sense, your IDE doesn't misbehave maybe just becasue
it doesn't let you change how it internally works.

If there is a "full power" language to change how your tool works, of
course you can do any nasty thing.
But actually the debug environment for elisp is very powerful and nice
to use.

Try to randomly modify some internal configuration files and then tell
me how your wonderful IDE helped you to fix the problem.

To me it seems (no offense) that you should just try to learn more
emacs/elisp.

Re: c/c++ project management and debugging

[Pascal J. Bourguignon]

Rajinder Yadav <devguy.ca@gmail.com> writes:

> it's only madness to you, to me its just another choice, how is having
> emacs generating a make file even a simple one to get you going a IDE?
> now you don't seem to fully understand IDE then =)

1- Makefiles need to be written by hand, because that's where you put
   the construction _rules_ specific to your project.

2- The dependencies between the files are probably what people don't
   like about Makefiles, but nobody told you to make them by hand!
   There are tools to generate them.  Namely, gcc -M.

So when you modify your #include you only have to type make depends to
have the Makefile.depends be updated.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Re: c/c++ project management and debugging

[despen]

Rajinder Yadav <devguy.ca@gmail.com> writes:

> On 10-12-20 08:28 PM, Andrea Crotti wrote:
>> Rajinder Yadav<devguy.ca@gmail.com>  writes:
>>
>>
>>> yes i already have cedet installed and working, but i would rather not
>>> write makefiles by hand. i understand there is also autoconf that can
>>> be used to generate makefiles, possible that's a better way to go,
>>> still i don't feel like investing the time to learn about autoconf at
>>> this point and time
>>
>> There is also cmake otherwise.
>> The problem is that or
>> - you learn a bit the autoconf skills you need (doesn't take long)
>>    and finally write your own build systems
>> - you'll be stuck forever with what other people (microsoft/cedet)
>>    thik is a good idea, and normally it isn't
>>
>> Using emacs I think it doesn't make any sense to look for tools that
>> write makefiles for you...
>
>
> Andrea, thanks for your reply!
>
> My reply here is not a direct response to you, but what i feel in
> general (a windows IDE guy in a Linux command line world)
>
> I don't quite understand the rational against emacs + auto makefile
> generation, it kind of hinders progress imho? if someone doesn't like
> the way emacs or netbean does things (for them) with makefiles, they
> always have the choice of doing it by hand, that is the beauty of
> having more choices, so stop taking away my choices if I simply ask or
> enquire for feature y!

I don't quite understand what these comments are about.
I keep seeing references to the cedet project and it certainly
claims to write Makefiles:

http://cedet.sourceforge.net/ede.shtml

Isn't that good enough?

As I said, I don't use code generators and I don't want a
machine generated Makefile.  I think hand created Makefiles
are more useful.  That's what makes a world.

If you want a machine generated Makefile, go for it.
Tell us how it works (or fails to work).

Saying Emacs can't do something, is a demonstration of
ignorance.  The Emacs Lisp engine is a full fledged programming
environment.  There is nothing Emacs can't do.  There may not be
a package yet that does what you want, but there always could be.

Re: c/c++ project management and debugging

[Richard Riley]

despen@verizon.net writes:

> Rajinder Yadav <devguy.ca@gmail.com> writes:
>
>> On 10-12-20 08:28 PM, Andrea Crotti wrote:
>>> Rajinder Yadav<devguy.ca@gmail.com>  writes:
>>>
>>>
>>>> yes i already have cedet installed and working, but i would rather not
>>>> write makefiles by hand. i understand there is also autoconf that can
>>>> be used to generate makefiles, possible that's a better way to go,
>>>> still i don't feel like investing the time to learn about autoconf at
>>>> this point and time
>>>
>>> There is also cmake otherwise.
>>> The problem is that or
>>> - you learn a bit the autoconf skills you need (doesn't take long)
>>>    and finally write your own build systems
>>> - you'll be stuck forever with what other people (microsoft/cedet)
>>>    thik is a good idea, and normally it isn't
>>>
>>> Using emacs I think it doesn't make any sense to look for tools that
>>> write makefiles for you...
>>
>>
>> Andrea, thanks for your reply!
>>
>> My reply here is not a direct response to you, but what i feel in
>> general (a windows IDE guy in a Linux command line world)
>>
>> I don't quite understand the rational against emacs + auto makefile
>> generation, it kind of hinders progress imho? if someone doesn't like
>> the way emacs or netbean does things (for them) with makefiles, they
>> always have the choice of doing it by hand, that is the beauty of
>> having more choices, so stop taking away my choices if I simply ask or
>> enquire for feature y!
>
> I don't quite understand what these comments are about.
> I keep seeing references to the cedet project and it certainly
> claims to write Makefiles:
>
> http://cedet.sourceforge.net/ede.shtml
>
> Isn't that good enough?
>
> As I said, I don't use code generators and I don't want a
> machine generated Makefile.  I think hand created Makefiles
> are more useful.  That's what makes a world.


Why do you think that? "Useful" is something that helps. How can hand
written ones by "useful". You can always hand write ones : auto
generated ones are "useful" for the 99% of people who dont want to have
to go through the drudgery and mechanics of something as trite as
makefiles and dependency management.

Bottom line : if the feature is there you can ignore it. If its not,
people ignore emacs.

Re: c/c++ project management and debugging

[Jason Earl]

On Tue, Dec 21 2010, Rajinder Yadav wrote:

> On 10-12-20 08:28 PM, Andrea Crotti wrote:
>> Rajinder Yadav<devguy.ca@gmail.com>  writes:
>>
>>
>>> yes i already have cedet installed and working, but i would rather not
>>> write makefiles by hand. i understand there is also autoconf that can
>>> be used to generate makefiles, possible that's a better way to go,
>>> still i don't feel like investing the time to learn about autoconf at
>>> this point and time
>>
>> There is also cmake otherwise.
>> The problem is that or
>> - you learn a bit the autoconf skills you need (doesn't take long)
>>    and finally write your own build systems
>> - you'll be stuck forever with what other people (microsoft/cedet)
>>    thik is a good idea, and normally it isn't
>>
>> Using emacs I think it doesn't make any sense to look for tools that
>> write makefiles for you...
>
>
> Andrea, thanks for your reply!
>
> My reply here is not a direct response to you, but what i feel in
> general (a windows IDE guy in a Linux command line world)
>
> I don't quite understand the rational against emacs + auto makefile
> generation, it kind of hinders progress imho? if someone doesn't like
> the way emacs or netbean does things (for them) with makefiles, they
> always have the choice of doing it by hand, that is the beauty of
> having more choices, so stop taking away my choices if I simply ask or
> enquire for feature y!

To a certain extent I think that this is simply due to the fact that
historically Emacs did not handle this sort of task.  So Emacs' users
got used to creating a build system themselves.  Besides, for Free
Software development what you really want is not a simple Makefile, but
some sort of cross-platform build system.  The sort of "build system"
that Visual Studio (or Netbeans, or whatever) generates simply is not
going to work.  In fact, it is probably going to get in the way.

Fortunately, CEDET's EDE actually has pretty good support for
Autoconf/Automake, which despite its flaws, is still probably the most
popular cross-platform build system available.  In short, Emacs is
currently set to make significant progress in this area.

> guys like me from the visual IDE environment will have a smaller
> barrier to entry as a result, overtime we will pickup said skills of
> making a makefile by hand, using autoconf or cmake, etc.

This is precisely why it makes me so happy that GNU Emacs is finally
adding CEDET.  It may not be perfect (yet), but it basically has all of
the parts that Emacs needs to be competitive on this front.  The wacky
keystrokes are still a bit of a barrier for new people, but I personally
think that Emacs is a compelling choice as an editor.  It just needs to
become a better IDE.

> i've never had the need to create a makefile or edit one by hand when
> i code using visualstudio, all i care about is coding my project in
> C++ and getting on with life. people like me need a bridge when we
> come over to the open source world, when we start using linux or
> emacs, etc. most of the time we are met with ridicule about how absurd
> our needs and demands are, so opportunity is lost when some decide why
> bother with open source, etc. el

I agree.  When I learned Linux (and Emacs) I did so because I was a poor
student and I wanted a C compiler and I could not afford one for
DOS/Windows.  I learned to appreciate the GNU development tools, but I
was only willing to put in the time and effort it took to use them
because the alternative was to not be able to develop at all.

> i love ruby on rails hacking, i love doing everything from the command
> line, it's more faster and efficient coding a rails app when compared
> to doing it with netbeans + ide, or whatever IDE is out there!

I honestly think that part of the reason that Emacs has fallen behind
when it comes to acting like an IDE is that a programmer's editor (like
Emacs) and a set of good command-line tools is fairly competitive with
the best an IDE can offer, and it is far more flexible.

Still, a set of tools that help smooth out the learning curve would
certainly help.  CEDET's EDE is actually pretty good in this regard.  It
makes it very easy to create a simple Makefile, and it is still flexible
enough to be useful in fancy Autconf/Automake projects.

The only problem is that CEDET is not (yet) part of Emacs, and so there
are not many examples of how to use its tools.

> i can tell you i spent countless hours searching the net and reading
> stuff just to figure out how to use emacs and get it setup with stuffs
> like ido, ecb, cedet and yasnippet learning all the key binding and
> how to edit the .emacs files, the barrier to entry to become more
> efficient with "emacs" is high

Agreed.  On the bright side the Emacs development team is really trying
to make more frequent releases, and with the next version of Emacs CEDET
will come pre-installed and the ELPA packages already make it easy to
and yasnippet.  I don't use ECB, so I do not know about that.

The fact that Emacs is extensible is a good thing.  The fact that you
essentially have to build your own development environment from scratch
is not a good thing.  I think that this is something that the Emacs
development team is working on, and adding CEDET is certainly going to
help.

> i like having ecb for file browsing, i don't always use it, sometimes
> i use the file searching power of ido, but i have a choice when to use
> which in emacs
>
> i am very grateful to the open source community that has made emacs a
> better tool for me and many more that help answer all my questions on
> mailing list or write blogs.

They are a pretty helpful group, and once you get used to the tools they
do have their strengths.

>>> yes i discovered this gdb setting on the emacs-fu blog, however i
>>> have 2 questions
>>>
>>> 1) when i have EBC opened gdb-many-windows end up looking like a
>>> mess, is there a way to get it to work with EBC?
>>>
>>> 2) i can't figure out how to set breakpoint, can't i simple click
>>> someone in the source window to add a bp?
>>>
>>
>> For a breakpoint you can click, use the space bar or the standard
>> gdb: "b File.cpp:#line" or "b Class::function"
>>
>>
>
> clicking for me doesn't set the breakpoint when i have the source file
> open in the buffer, i am still in edit mode?
>
> i see many gdb windows, but where do I type, b File.cpp:#line ??
>
> here is what i do
>
> 1. open a simple .cpp source file in emacs, a hello world file in C++
> 2. m-x gdb
>
> source buffer disappears, replaced by gdb buffer
>
> 3 m-x gdb-many-windows
> i still don't see my source code window? now where do i click to set a
> break point?
>
> if i switch the gdb buffer to display my source code buffer, i can't
> type in the gdb command while still looking at my source buffer? how
> is one to work in this kind of setup

I don't use gdb-many windows.  I simply do M-x gdb and then when gdb
pops up I do C-x 2 to split the screen, C-x o to jump to the bottom
buffer, and C-x b to jump back to the source screen.  Then I set the
break point with C-x <space> in the source buffer and then use C-x o to
jump back to the gdb window.

I don't use the debugger much though, so I would not be surprised if
there is a better way.

> can i not have a source buffer and a gdb buffer open at the same time,
> still where do i click to set the break point?

I think that even with gdb-many-windows if you took one of the windows
and used C-x b to jump back to the source buffer you could set a break
point.

Jason

Re: c/c++ project management and debugging

[Elena]

On Dec 21, 8:08 pm, Jason Earl <je...@notengoamigos.org> wrote:
> The fact that Emacs is extensible is a good thing.  The fact that you
> essentially have to build your own development environment from scratch
> is not a good thing.  I think that this is something that the Emacs
> development team is working on, and adding CEDET is certainly going to
> help.

That pretty much summarizes my thinking.

Re: c/c++ project management and debugging

[Jason Earl]

On Mon, Dec 20 2010, Rajinder Yadav wrote:

> On Mon, Dec 20, 2010 at 8:47 AM, Andrea Crotti
> <andrea.crotti.0@gmail.com> wrote:
>> Rajinder Yadav <devguy.ca@gmail.com> writes:
>>
>>> up to now i've been using emacs for ruby on rails, i want to get setup
>>> so i can also do c/c++ development
>>>
>>> i come from a visualstudio ide background for c++ stuff, how can I
>>> setup emacs to integrate the gnu tool chain, such that i can have
>>> emacs generate makefiles and do the builds
>>>
>>> also how can i get a gui like ide gdb setup for debugging code
>>
>> Why, does visualstudio integrates with the gnu tool chain :O?
>> I guess not, but that's what I understood from your sentences...
>
> no i wanted emacs to integrate with the gnu tool chain
>
>> Anyway with Cedet you can do a lot of stuff.
>> It doesn't however generats any makefile, but if you learn to write them
>> is not time wasted at all...
>
> yes i already have cedet installed and working, but i would rather not
> write makefiles by hand. i understand there is also autoconf that can
> be used to generate makefiles, possible that's a better way to go,
> still i don't feel like investing the time to learn about autoconf at
> this point and time

There's no reason to write Makefiles by hand now that Emacs can do it
for you.  M-x ede-new to create a new project (choose a "Make" project),
then M-x customize-project.  For simple projects it is tons easier than
creating a Makefile by hand, especially considering all of the targets
that EDE gives you for free.

Plus, creating a project teaches Emacs how your project is organized.
Not only does this allow you to easily run the build from inside Emacs,
but it allows you to query and search your files by project as well.

>> Gdb integration works quite well already, the only important
>> parameter for gdb imho is (setq gdb-many-windows t)
>>
>> and then just try something you'll see if you like it.
>
> yes i discovered this gdb setting on the emacs-fu blog, however i have
> 2 questions
>
> 1) when i have EBC opened gdb-many-windows end up looking like a mess,
> is there a way to get it to work with EBC?
>
> 2) i can't figure out how to set breakpoint, can't i simple click
> someone in the source window to add a bp?

I hit C-x <space> in the source window.  There probably is a way to use
the mouse.  To be honest, I don't use the debugger much.  I probably
should.

Jason

Re: c/c++ project management and debugging

[Rajinder Yadav]

On Tue, Dec 21, 2010 at 12:13 AM, Jason Earl <jearl@notengoamigos.org> wrote:
> On Mon, Dec 20 2010, Rajinder Yadav wrote:
>
>> On Mon, Dec 20, 2010 at 8:47 AM, Andrea Crotti
>> <andrea.crotti.0@gmail.com> wrote:
>>> Rajinder Yadav <devguy.ca@gmail.com> writes:
>>>
>>>> up to now i've been using emacs for ruby on rails, i want to get setup
>>>> so i can also do c/c++ development
>>>>
>>>> i come from a visualstudio ide background for c++ stuff, how can I
>>>> setup emacs to integrate the gnu tool chain, such that i can have
>>>> emacs generate makefiles and do the builds
>>>>
>>>> also how can i get a gui like ide gdb setup for debugging code
>>>
>>> Why, does visualstudio integrates with the gnu tool chain :O?
>>> I guess not, but that's what I understood from your sentences...
>>
>> no i wanted emacs to integrate with the gnu tool chain
>>
>>> Anyway with Cedet you can do a lot of stuff.
>>> It doesn't however generats any makefile, but if you learn to write them
>>> is not time wasted at all...
>>
>> yes i already have cedet installed and working, but i would rather not
>> write makefiles by hand. i understand there is also autoconf that can
>> be used to generate makefiles, possible that's a better way to go,
>> still i don't feel like investing the time to learn about autoconf at
>> this point and time
>
> There's no reason to write Makefiles by hand now that Emacs can do it
> for you.  M-x ede-new to create a new project (choose a "Make" project),
> then M-x customize-project.  For simple projects it is tons easier than
> creating a Makefile by hand, especially considering all of the targets
> that EDE gives you for free.
>
> Plus, creating a project teaches Emacs how your project is organized.
> Not only does this allow you to easily run the build from inside Emacs,
> but it allows you to query and search your files by project as well.

Thanks Jason,

I knew there had to already be a way! What is EDE? Does it come with
CEDET or Emacs? I don't know much about CEDET yet other then I like
the syntax highlighting it gives me =)

>>> Gdb integration works quite well already, the only important
>>> parameter for gdb imho is (setq gdb-many-windows t)
>>>
>>> and then just try something you'll see if you like it.
>>
>> yes i discovered this gdb setting on the emacs-fu blog, however i have
>> 2 questions
>>
>> 1) when i have EBC opened gdb-many-windows end up looking like a mess,
>> is there a way to get it to work with EBC?
>>
>> 2) i can't figure out how to set breakpoint, can't i simple click
>> someone in the source window to add a bp?
>
> I hit C-x <space> in the source window.  There probably is a way to use
> the mouse.  To be honest, I don't use the debugger much.  I probably
> should.
>
> Jason
>



-- 
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1

Re: c/c++ project management and debugging

[Rajinder Yadav]

On Tue, Dec 21, 2010 at 9:36 AM, Rajinder Yadav <devguy.ca@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 12:13 AM, Jason Earl <jearl@notengoamigos.org> wrote:
>> On Mon, Dec 20 2010, Rajinder Yadav wrote:
>>
>>> On Mon, Dec 20, 2010 at 8:47 AM, Andrea Crotti
>>> <andrea.crotti.0@gmail.com> wrote:
>>>> Rajinder Yadav <devguy.ca@gmail.com> writes:
>>>>
>>>>> up to now i've been using emacs for ruby on rails, i want to get setup
>>>>> so i can also do c/c++ development
>>>>>
>>>>> i come from a visualstudio ide background for c++ stuff, how can I
>>>>> setup emacs to integrate the gnu tool chain, such that i can have
>>>>> emacs generate makefiles and do the builds
>>>>>
>>>>> also how can i get a gui like ide gdb setup for debugging code
>>>>
>>>> Why, does visualstudio integrates with the gnu tool chain :O?
>>>> I guess not, but that's what I understood from your sentences...
>>>
>>> no i wanted emacs to integrate with the gnu tool chain
>>>
>>>> Anyway with Cedet you can do a lot of stuff.
>>>> It doesn't however generats any makefile, but if you learn to write them
>>>> is not time wasted at all...
>>>
>>> yes i already have cedet installed and working, but i would rather not
>>> write makefiles by hand. i understand there is also autoconf that can
>>> be used to generate makefiles, possible that's a better way to go,
>>> still i don't feel like investing the time to learn about autoconf at
>>> this point and time
>>
>> There's no reason to write Makefiles by hand now that Emacs can do it
>> for you.  M-x ede-new to create a new project (choose a "Make" project),
>> then M-x customize-project.  For simple projects it is tons easier than
>> creating a Makefile by hand, especially considering all of the targets
>> that EDE gives you for free.
>>
>> Plus, creating a project teaches Emacs how your project is organized.
>> Not only does this allow you to easily run the build from inside Emacs,
>> but it allows you to query and search your files by project as well.
>
> Thanks Jason,
>
> I knew there had to already be a way! What is EDE? Does it come with
> CEDET or Emacs? I don't know much about CEDET yet other then I like
> the syntax highlighting it gives me =)

ok I just realized EDE is at the top of CEDET home poage, will take
another look at this project feature!

-- 
Kind Regards,
Rajinder Yadav | DevMentor.org | Do Good! ~ Share Freely

GNU/Linux: 2.6.35-22-generic
Kubuntu x86_64 10.10 | KDE 4.5.1
Ruby 1.9.2p0 | Rails 3.0.1

Re: c/c++ project management and debugging

[Elena]

On Dec 20, 11:39 am, Rajinder Yadav <devguy...@gmail.com> wrote:
> up to now i've been using emacs for ruby on rails, i want to get setup
> so i can also do c/c++ development

If you are from Visual Studio, you are up for disappointment.  Emacs
is not an IDE, use Eclipse or Netbeans.

Re: c/c++ project management and debugging

[Dmitriy Igrishin]

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

Hey all,

2010/12/20 Elena <egarrulo@gmail.com>

> On Dec 20, 11:39 am, Rajinder Yadav <devguy...@gmail.com> wrote:
> > up to now i've been using emacs for ruby on rails, i want to get setup
> > so i can also do c/c++ development
>
> If you are from Visual Studio, you are up for disappointment.  Emacs
> is not an IDE, use Eclipse or Netbeans.
>
> When I've started to learn C++ I've been disappointed by following IDEs
(not IDEs but just modules for Java-based platforms): Eclipse CDT,
Netbeans C/C++, Visual Studio, CodeLite, CodeBlocks, Anjuta and many
others. Also I've been disappointed by vim editor. Only Xcode experience
I've liked but anyway I've dissatisfied with it also.
And only with Emacs I've been satisfied. So please don't tell tales about
"modern" approaches of development and how IDEs are good. If you like
IDE -- use IDE, but please don't impose you opinion to others. Because
"IDE is panacea" is a FALSE.
I know many really good C++ libraries developed in Emacs.  And personally
I happy to Emacs to code in C++.

-- 
// Dmitriy.

[-- Attachment #2: Type: text/html, Size: 1526 bytes --]