I'm using python.el If I choose 'debugger' from the menu, and enter 'python -m pdb myfile.py', gud starts, and in a split frame I see the (Pdb) prompt in one, and my python code in the other with a caret on the first line, indicating that it's ready to go. For example 'n' steps to the next line and the caret moves accordingly.
If instead I enter 'python -m ipdb myfile.py', the frame splits, and one split is labeled gud, but there's no ipdb console evident. In other words, this way of starting ipdb doesn't seem to work. Ipdb works just fine if I manually insert a breakpoint into my python code using ipdb.set_trace(), except that it does not use the gud interface. Is this intentional so that ipdb's stack trace will work nicely?
If so, that's fine, but is there a way to start ipdb from emacs without manually adding a set_trace() command?
The basic problem here is that gud is looking for a
(Pdb)prompt and ipdb doesn't prompt this way. There are three ways to fix this: fix ipdb to give a(Pdb)prompt, fix gud not to need to look for(Pdb)or (my favorite) use something else either on the gud side or on the ipdb side.The problem with fixing up gud is that it is rather old and to my mind a bit creaky using global variables and not making use of Emacs Lisp data structures available other than lists and cons cells. A total rewrite of gud is called realgud, it is currently in MELPA and ELPA. And ipdb is supported.
The last option is to use something else, so let me suggest the Python trepan debugger which is already integrated into realgud (but not gud since I consider that a dead end). Although the backtraces it gives are not exactly like ipdb's, it does colorize them and the source code.
And recent versions of trepan3k backtraces will even show, on demand, you where in the line you are. So if you had say two calls of a function, like
fib()it would distinguish which of the calls function was the one in progress.