[Python-mode] Re: python-mode.el interferes with GUD

[Peter Hendrickson]

Skip Montaro wrote:
>> Peter> GUD ("M-x gdb") places a "=>" indicator in front of the current
>> Peter> source line in a file which is being debugged.  When
>> Peter> python-mode.el has been loaded, this feature is nearly useless.
>> Peter> The "=>" is visible only for an instant - if it is visible at
>> Peter> all.  This makes it impossible to do anything useful with the
>> Peter> debugger.
>
> This seems familiar.  I thought the topic came up before, though I
> thought the conclusion was that either recent versions of
> python-mode.el don't exhibit this problem or that Barry couldn't
> reproduce it.
>
>> Peter> I've seen this with GNU Emacs 21.2.1 and python-mode.el Revision
>> Peter> 4.35.  If there's any problem reproducing the behavior, please
>> Peter> let me know and I will do more experiments with different
>> Peter> machines and different versions of Emacs.
>
> Yes, please.  Can you try with the latest version of python-mode.el?
> Any chance you can try it with XEmacs of some vintage?  Neither
> Barry nor I use GNU Emacs.

The problem occurs with GNU Emacs 21.2.1 and python-mode.el Revision
4.41, too.  (And GNU Emacs 21.3.1, but running on a different system.)
Curiously, it does *not* occur with XEmacs 21.4 (Patch 6) and the same
version of python-mode.el.

Barry Warsaw wrote:
> This does come up occasionally, and I'm pretty sure it's a GNU Emacs
> problem.  I've never been able to reproduce it on XEmacs.

I've been poking around and I think what's happening is this:
(py-pdbtrack-overlay-arrow) sets overlay-arrow-position to nil, which
causes the arrow to be turned off when emacs does a redisplay.
((py-pdbtrack-overlay-arrow nil) is apparently called when
(py-pdbtrack-track-stack-file) isn't supposed to be doing anything.)

Normally, the arrow is turned on in (gud-display-line) in gud.el by
setting the overlay-arrow-position and overlay-arrow-string.  But,
subsequently the comint-output-filter-functions are run so
(py-pdbtrack-overlay-arrow nil) is called, which then sets
overlay-arrow-position to nil - and turns off the arrow.  You can
occasionally see the ghostly flicker of the arrow before it's cleared
by (py-pdbtrack-overlay-arrow), in fact.

I believe the intention of (py-pdbtrack-overlay-arrow nil) is to be
neutral, but turning off the arrow is not neutral behavior.  I don't
think this can be reasonably described as a GNU Emacs bug.

In my last message I recommended commenting out two lines,
but actually you only need to comment out the line below:
> (defun py-pdbtrack-overlay-arrow (activation)
>   "Activate or de arrow at beginning-of-line in current buffer."
>   ;; This was derived/simplified from edebug-overlay-arrow
>   (cond (activation
> 	 (setq overlay-arrow-position (make-marker))
> 	 (setq overlay-arrow-string "=>")
> 	 (set-marker overlay-arrow-position (py-point 'bol) (current-buffer))
> 	 (setq py-pdbtrack-is-tracking-p t))
> 	(overlay-arrow-position
> ;; This line breaks M-x gdb. --pdh
> ;;	 (setq overlay-arrow-position nil)
> 	 (setq py-pdbtrack-is-tracking-p nil))
> 	))

This might have the effect of leaving an extra overlay arrow around
when actually using pdb commands in python-mode.el, so there might be
a better way to do it.

Xemacs appears to have a significantly different approach to M-x gdb.
There doesn't seem to be a gud.el file, for example.  I'm not sure why
it works in the Xemacs environment, but my guess is that the order in
which certain commands are called is different or the design of
overlay-arrow-position is not the same.

Peter