bug#13586: pdbtrack doesn't jump to the source file location on the first exception/set_trace() call

[Greg Novak <greg.novak@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]

I have attached a patch to fix this problem.

I am using the latest stable version of emacs 24.2.1, but with the version
of python.el written by Fabián E. Gallina from the latest development emacs
sources.

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.

I have attached 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.

Below is an example of extra information printed when python encounters a
call to pdb.set_trace().  pdbtrack requires the stack frame to be on the
first or second line, but in this case the first and second lines are '1.1'
and '--Return--'  (The code in question is not printing anything to stdout).

>>> mg.jey()
1.1
--Return--
> /Users/novak/Projects/gsnpy/mg.py(17)gsn()->None
-> pdb.set_trace()
(Pdb) up

[-- Attachment #1.2: Type: text/html, Size: 2047 bytes --]

[-- Attachment #2: python.el.diff --]
[-- Type: application/octet-stream, Size: 1932 bytes --]

*** python.el.orig	2013-01-29 13:13:49.000000000 +0100
--- python.el	2013-01-29 17:09:34.000000000 +0100
***************
*** 2323,2337 ****
             (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)))))