When running python or ipython under Emacs, when either an exception or a call to pdb.set_trace() is encountered, pdbtrack doesn't immediately jump to the appropriate line of the offending source file. In the case of pdb.set_trace(), this is because a few extra lines of information are printed involving the arguments of the present function (see below), and the implementation of pdbtrack in python.el requires the stack information to be on the first or second line of the most recent comint output. If I type 'up', then 'down' to move between the stack frames, pdbtrack finds the stack frame info and jumps to the source file as desired.
When using IPython, ipdb generally prints an entire stack trace, so it's necessary to find the line corresponding to the last stack frame printed.
At the bottom I have copied a context diff of the change required to fix this behavior so that pdbtrack immediately jumps to the desired source file, rather than requiring me to type 'up' then 'down' to move between stack frames so that one and only one stack frame is printed.
Example of extra info when encountering pdb.set_trace():
mg.jey()
1.1
--Return--
/Users/novak/Projects/gsnpy/mg.py(17)gsn()->None
-> pdb.set_trace()
(Pdb) up
*** python.el.orig 2013-01-29 16:50:48.000000000 +0100
--- python.el 2013-01-29 17:08:13.000000000 +0100
***************
*** 2300,2314 ****
(file-name
(with-temp-buffer
(insert full-output)
! (goto-char (point-min))
! ;; OK, this sucked but now it became a cool hack. The
! ;; stacktrace information normally is on the first line
! ;; but in some cases (like when doing a step-in) it is
! ;; on the second.
! (when (or (looking-at python-pdbtrack-stacktrace-info-regexp)
! (and
! (forward-line)
! (looking-at python-pdbtrack-stacktrace-info-regexp)))
(setq line-number (string-to-number
(match-string-no-properties 2)))
(match-string-no-properties 1)))))
--- 2300,2316 ----
(file-name
(with-temp-buffer
(insert full-output)
! ;; When the debugger encounters a pdb.set_trace()
! ;; command, it prints a single stack frame. Sometimes
! ;; it prints a bit of extra information about the
! ;; arguments of the present function. When ipdb
! ;; encounters an exception, it prints the _entire_ stack
! ;; trace. To handle all of these cases, we want to find
! ;; the _last_ stack frame printed in the most recent
! ;; batch of output, then jump to the corrsponding
! ;; file/line number.
! (goto-char (point-max))
! (when (re-search-backward python-pdbtrack-stacktrace-info-regexp nil t)
(setq line-number (string-to-number
(match-string-no-properties 2)))
(match-string-no-properties 1)))))
I have attached a patch to fix this problem.
When running python or ipython under Emacs, when either an exception or a call to pdb.set_trace() is encountered, pdbtrack doesn't immediately jump to the appropriate line of the offending source file. In the case of pdb.set_trace(), this is because a few extra lines of information are printed involving the arguments of the present function (see below), and the implementation of pdbtrack in python.el requires the stack information to be on the first or second line of the most recent comint output. If I type 'up', then 'down' to move between the stack frames, pdbtrack finds the stack frame info and jumps to the source file as desired.
When using IPython, ipdb generally prints an entire stack trace, so it's necessary to find the line corresponding to the last stack frame printed.
At the bottom I have copied a context diff of the change required to fix this behavior so that pdbtrack immediately jumps to the desired source file, rather than requiring me to type 'up' then 'down' to move between stack frames so that one and only one stack frame is printed.
Example of extra info when encountering pdb.set_trace():