Re: c/c++ project management and debugging

[Elena <egarrulo@gmail.com>]

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.