Kent Borg <[email protected]> writes: > On 01/17/2018 12:31 PM, Kent Borg wrote: >> It has its advantages, it has its drawbacks, but then I stumbled on >> a *big* problem: source code debugging with pdb quit working. Emacs >> used to open another pane and put an arrow next to the line about to >> be executed. No longer. Naturally I suspect elpy. > > I think I have a workaround... > > I usually invoke pdb by dropping in my code: > > import pdb ; pdb.set_trace() > > But I tried meta-X pdb and got an error, something about a string > being nil? (I didn't write it down.) I tried tracing in emacs...and > that make it work. I reboot and "import pdb ; pdb.set_trace()" fails, > but meta-X > pdb works...but thereafter it seems "import pdb ; pdb.set_trace()" now > works. > > Weird.
So emacs has two debuggers. Even if you don't want to learn edebug (which is too bad because it's my favourite debugger -- seriously, I'd rather write elisp than common lisp or scheme cause I know no debugger that compares to edebug -- way better than gdb and Perl's debugger), you could at least get a stack trace by setting debug-on-error to true before you reproduce the issue. What you describe sounds like a module not loading early enough. Something loads when you m-X pdb because of an autoload or whatever, something that the other way can't make happen since that way is only between, uh, what?, your python interpreter and the comint/gud/gdb buffer. -- Mike Small [email protected] _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
