From barry at python.org  Sun Aug  3 19:04:23 2003
From: barry at python.org (Barry Warsaw)
Date: Sun Aug  3 14:29:50 2003
Subject: [Python-mode] Re: [Python-Dev] python-mode category?
In-Reply-To: <16173.17905.405720.713386@montanaro.dyndns.org>
References: <16173.4812.720842.928425@montanaro.dyndns.org>
	<Pine.LNX.4.44.0308030954500.12633-100000@korak.zope.com>
	<16173.17905.405720.713386@montanaro.dyndns.org>
Message-ID: <1059933829.5784.1.camel@anthem>

CC'ing the list for posterity...

On Sun, 2003-08-03 at 13:27, Skip Montanaro wrote:
> Guys,
> 
> I'd feel better if one of you did this.  I'm having trouble even accessing
> SF at the moment.  It keeps asking me for a password when trying 
> 
>     cvs -d montanaro@cvs.python-mode.sourceforge.net:/cvsroot/python-mode co python-mode
> 
> or
> 
>     cvs -d montanaro@cvs.sourceforge.net:/cvsroot/python-mode co python-mode
> 
> I expected it to give me an error because the repository is empty, but not
> prompt me for my password (and not like it when I gave it).
> 
> I think we should just have a module named python-mode with a single file,
> python-mode.el.  If I understood Ken's note correctly, importing it in with
> a branch arg of "-b 4.38.1" would give a version of 4.38 to an initial
> checkout of python-mode.el, yes?  (CVS branches baffle me, so I feel I have
> to ask, because the ".1" means nothing to my cvs-naive brain.)

I just created the minimal cvs directory structure.  You should be able
to cvs co python-mode now.

I'm going to do a SF admin request to get Misc/python-mode.el,v copied
here so we don't lose history.  That should also take care of the
current revision.  Don't touch Misc/python-mode.el until then!

-Barry



From skip at pobox.com  Sun Aug  3 14:18:56 2003
From: skip at pobox.com (Skip Montanaro)
Date: Sun Aug  3 14:29:50 2003
Subject: [Python-mode] Re: [Python-Dev] python-mode category?
In-Reply-To: <1059933829.5784.1.camel@anthem>
References: <16173.4812.720842.928425@montanaro.dyndns.org>
	<Pine.LNX.4.44.0308030954500.12633-100000@korak.zope.com>
	<16173.17905.405720.713386@montanaro.dyndns.org>
	<1059933829.5784.1.camel@anthem>
Message-ID: <16173.21008.808733.320560@montanaro.dyndns.org>


    Barry> CC'ing the list for posterity...

Ah, thanks.  I guess I should subscribe...

    Barry> I just created the minimal cvs directory structure.  You should
    Barry> be able to cvs co python-mode now.

Alas, I still get password prompts and it still doesn't like what I type.  I
can ssh into shell1.sourceforge.net without a password and cvs up my Python
tree just fine.  I'll file a support request at SF.

Skip

From david.se at home.se  Mon Aug  4 15:33:44 2003
From: david.se at home.se (David Hemmingsson)
Date: Mon Aug  4 09:06:26 2003
Subject: [Python-mode] Indent bug(?)
Message-ID: <1060000424.7c1579e0david.se@home.se>

Thanks for a nice emacs mode!

But today I found that the indentation didnt work when I tried the following:

filen.write("<style type=\"text/css\">\n")
filen.write("a:link{ text-decoration:none; color:#ffffff}\n")
filen.write("a:visited\{ text-decoration:none\; color:#ffffff\}\n")
filen.write("a:active\{ text-decoration:none\; color:#ffffff\} </style>\n")  

If these lines are written and you auto indent them & well, see for yourself.  Of course Its the ':'-sign that is the problem. Can you solve it?

/David Hemmingsson


From skip at pobox.com  Mon Aug  4 22:57:59 2003
From: skip at pobox.com (Skip Montanaro)
Date: Mon Aug  4 22:58:09 2003
Subject: [Python-mode] Whew!  Finally got a cvs checkout the hard way
Message-ID: <16175.7479.197762.527988@montanaro.dyndns.org>


It took me quite awhile to figure out why I couldn't successfully check out
the python-mode tree.  After much futzing around, I finally got the -v flag
set on the underlying ssh command.  It showed me that when I ran 'cvs up' in
a preexisting tree, ssh read the entry in my .ssh/config file for
*.sourceforge.net.  When I ran 'cvs co', however, that entry was not being
read for some unknown reason, so ssh was trying to authenticate me on SF as
"skip" instead of "montanaro".  After a small amount of fiddling (manually
creating a top-level CVS directory and corresponding entries), I was able to
simply "cvs up" the python-mode project.

Man, what a pain!  Now I can turn my attention to migrating the existing
open python-mode items from the python project to the python-mode project.

Skip


From skip at pobox.com  Mon Aug  4 23:19:17 2003
From: skip at pobox.com (Skip Montanaro)
Date: Mon Aug  4 23:19:27 2003
Subject: [Python-mode] 567468 - Open or Closed?
Message-ID: <16175.8757.695801.346984@montanaro.dyndns.org>

Barry,

http://python.org/sf/567468 is marked "Open" and "Rejected".  Is the lack of
"Closed" merely an oversight or did you have some reservations about
rejecting the patch?

Thx,

Skip

From barry at python.org  Tue Aug  5 04:21:30 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Aug  4 23:21:31 2003
Subject: [Python-mode] Whew!  Finally got a cvs checkout the hard way
In-Reply-To: <16175.7479.197762.527988@montanaro.dyndns.org>
References: <16175.7479.197762.527988@montanaro.dyndns.org>
Message-ID: <1060053657.1042.22.camel@geddy>

On Mon, 2003-08-04 at 22:57, Skip Montanaro wrote:

> 
> Man, what a pain!  Now I can turn my attention to migrating the existing
> open python-mode items from the python project to the python-mode project.

SF copied python-mode.el,v to the python-mode project, so we won't lose
any cvs history on the most important file.  Everything else is up for
grabs.

-Barry



From barry at python.org  Tue Aug  5 04:40:05 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Aug  4 23:40:06 2003
Subject: [Python-mode] 567468 - Open or Closed?
In-Reply-To: <16175.8757.695801.346984@montanaro.dyndns.org>
References: <16175.8757.695801.346984@montanaro.dyndns.org>
Message-ID: <1060054773.1042.35.camel@geddy>

On Mon, 2003-08-04 at 23:19, Skip Montanaro wrote:
> Barry,
> 
> http://python.org/sf/567468 is marked "Open" and "Rejected".  Is the lack of
> "Closed" merely an oversight or did you have some reservations about
> rejecting the patch?

I had some reservations because it seemed to me the patch was
unnecessary under XEmacs and I could never get it to work properly on
Emacs (but then you know I can barely get Emacs to fire up these days
:).

I don't remember whether it's still relevant.

-Barry



From noreply at sourceforge.net  Mon Aug  4 21:11:48 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:47:57 2003
Subject: [Python-mode] [ python-mode-Bugs-783240 ] python-mode loops on
	if/else
Message-ID: <E19jsEm-00044Z-00@sc8-sf-web3.sourceforge.net>

Bugs item #783240, was opened at 2003-08-04 22:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581349&aid=783240&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode loops on if/else

Initial Comment:
(migrating from python project)

Original submission:

Here's how to reproduce.  Create a .py file in XEmacs 
 containing this text: 
  
 x = (if 1: 2 
  ____else: 3) 
  
 (except that the ____ really means four spaces). 
  
 Now position your cursor somewhere inside those 4 
 spaces, and hit TAB. XEmacs freezes until you hit 
^G.

Followup comments:

Date: 2003-07-31 22:41
Sender: montanaro
Logged In: YES 
user_id=44345

The code gets into an infloop in py-outdent-p.  The 
loop looks
odd to me:

  (while (or (looking-at py-blank-or-comment-re)
                (bobp))
     (backward-to-indentation 1))

If you were at (bobp), why would you want to try to 
move back
a line?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581349&aid=783240&group_id=86916

From noreply at sourceforge.net  Mon Aug  4 21:14:10 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:47:57 2003
Subject: [Python-mode] [ python-mode-Bugs-783241 ] python-mode.el: sexp
	commands don't understand Python
Message-ID: <E19jsH4-00049Y-00@sc8-sf-web3.sourceforge.net>

Bugs item #783241, was opened at 2003-08-04 22:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581349&aid=783241&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode.el: sexp commands don't understand Python

Initial Comment:
migrating from the python project.

Original submission:

Emacs has a whole lot of commands dealing with 
'sexps', 
 such as forward-sexp and kill-sexp.  These originated 
 with Lisp but are useful for other languages too.  For 
 example in c-mode, editing the text 
  
 if (x > 7) { 
     puts("hello"); 
 } 
  
 with point before the 'i', pressing M-C-k (kill-sexp) 
 will first kill the 'if' keyword, leaving: 
  
  (x > 7) { 
     puts("hello"); 
 } 
  
 Then a second press of M-C-k leaves 
  
  { 
     puts("hello"); 
 } 
  
 and a third press kills the whole block following.  So 
 you can kill the whole if-statement, and nothing 
more, 
 with three keypresses.  This is useful for moving 
 chunks of code around. 
  
 However the same doesn't work in python-mode 
because 
 Emacs doesn't appear to know about the definition of 
a 
 sexp.  You can kill balanced expressions on a 
 particular line but it's not possible to remove the 
 whole of an 'if' or 'while' block. 
  
 Along the same lines, while commands like mark-
defun 
 work in most languages to select the current function 
 definition, they don't work with Python's 'def' blocks, 
 instead highlighting the whole file. 
  
 Is it possible to get these and similar commands 
 working, or is Emacs hardwired to look for starting 
and 
 ending delimiters around each block?  If it's not 
 possible to make these commands work correctly, it 
 might be better to disable them for python-mode 
rather 
 than leave them present but wrong (eg mark-defun 
marks 
 the whole buffer).

No followup comments.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581349&aid=783241&group_id=86916

From noreply at sourceforge.net  Mon Aug  4 21:22:55 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:47:58 2003
Subject: [Python-mode] [ python-mode-Patches-783248 ] Make python-mode.el
	use "jython" interp
Message-ID: <E19jsPX-0003SB-00@sc8-sf-web1.sourceforge.net>

Patches item #783248, was opened at 2003-08-04 22:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783248&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make python-mode.el use "jython" interp

Initial Comment:
migrating #574750 from python project.

Original submission:

I believe it is time to start using the "jython" 
 interpreter by default, rather than the "jpython" 
 interpreter. 
  
 This patch does it in a minimal way, just changing 
the 
 command and acknowledging the two names.  (I still 
 prefer the JPython name, but...)

Followup comments:

Date: 2002-07-28 11:00
Sender: loewis
Logged In: YES 
user_id=21627

Please use context or unified diffs for patches; I'm
attaching your change as a diff.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783248&group_id=86916

From noreply at sourceforge.net  Mon Aug  4 21:26:19 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:47:58 2003
Subject: [Python-mode] [ python-mode-Patches-783254 ] python-mode patch for
	ipython support
Message-ID: <E19jsSp-0003bq-00@sc8-sf-web1.sourceforge.net>

Patches item #783254, was opened at 2003-08-04 22:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783254&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode patch for ipython support

Initial Comment:
migrating #575774 from the python project.

Original submission:

This patch makes the prompt and traceback 
recognition 
 mechanisms a bit more flexible to allow easy 
adaptation 
 for ipython (in lieu of the normal python shell). The 
 seperate file ipython.el (which I assume will end up in 
 the ipython distribution) then enables 
 py-execute-region, py-up-exception etc. to work just 
as 
 well for ipython (which means ipython works just as 
 well under python mode as the standard python 
shell). I 
 also added something to ipython.el to convert 
ipython 
 session bits to something that looks like normal 
 interactive session bits. This, together with ipython's 
 ability to directly execute such strings (by 
 auto-removing leading '>>>'s) should make for very 
 convinient doctest development (I had orginally 
planned 
 to patch python-mode to incorporate such 
functionality 
 because I found the manual reediting a bit tiresome). 
  
 Slightly off-topic, I also have a feature request: 
 executing a whole file ends up creating a temporary 
 file which is instead executed. I think it would be 
 much nicer if the actual file itself where executed 
 with execfile, because otherwise pdb ends up 
pointing 
 to the "wrong" (i.e. the temporary) buffer. It is 
 really easy to forget about this and edit this 
 temporary file during a debugging session and as a 
 consequence inadvertenly loose changes. This 
situation 
 crops up quite often, if one uses ipython's really 
 nifty feature to toggle pdb activation on exceptions 
 (or hacks up something equivalent for python), which 
is 
 an extremely efficient way to quickly debug and test 
 one's program. I would have added a patch, but 
some 
 restructuring seemed necessary, and it wasn't 
 immediately clear to me in which way this should be 
done.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783254&group_id=86916

From noreply at sourceforge.net  Mon Aug  4 21:29:27 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:47:59 2003
Subject: [Python-mode] [ python-mode-Patches-783259 ] More flexible py-shell
	interpreter selection
Message-ID: <E19jsVr-0003ih-00@sc8-sf-web1.sourceforge.net>

Patches item #783259, was opened at 2003-08-04 22:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783259&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: More flexible py-shell interpreter selection

Initial Comment:
migrating #675034 from python project.

Original Submission:

Currently in python-mode.el, py-which-shell (the 
 command used to start the python interpreter) is 
 limited to "python" or "jpython".  This patch makes it 
 possible to specify an arbitrary command at 
invocation 
 time, including a command that is specified relative 
to 
 the current path. 
  
 The problem: I am working on a project where jython 
is 
 embedded within our application.  The application 
 optionally allows console access to the jython 
 interpreter.  The application is started by running a 
 shell script which sets some environment variables 
then 
 invokes the jython interpreter with a large number of 
 arguments. 
  
 I would like to use py-shell within emacs to interact 
 with the application.  However, it is impractical to 
 start the application under py-shell for two reasons: 
  
 1. The command that needs to be invoked is neither 
 "python" nor "jython", and in fact would require 
many 
 arguments; 
  
 2. The command is not necessary installed in the 
PATH. 
  
 Similar problems occur even if one sometimes wants 
to 
 start an alternative python interpreter (such as 
 "python2" under redhat) or an interpreter that is not 
 in PATH (for example, if testing a new version of 
 python). 
  
 Therefore I have written a patch to python-mode.py 
that 
 changes the py-shell command as follows: 
  
 + If there is no prefix argument, the usual python (or 
 jython) interpreter is invoked without further 
 interaction as before. 
  
 + If there is a prefix argument, then the user is 
asked 
 what command to invoke with the "standard 
command" as 
 the default input: 
  
     command: python -i 
  
 The user can edit the command to run whatever s/he 
 wants. 
  
 + The command typed by the user is invoked via 
"$SHELL 
 -c 'COMMAND'" so that the user's program is first 
 sought in the emacs default directory (generally, the 
 directory related to the current emacs buffer).  This 
 allows the user to type, for example, 
  
     command: ./my_test_interpreter -i 
  
 I am a novice at emacs lisp, but the patch is simple 
 (only about 10 lines changed) and it seems to work 
for 
 me. 
  
 The patch applies to the CVS version of python-
mode.el 
 as of today (2003-01-26), but the same patch can 
be 
 applied to the version that was released with 
 Python-2.1.

Followup comments:

Date: 2003-02-03 04:45
Sender: mhagger
Logged In: YES 
user_id=38106

The two patches are largely orthogonal.  This patch 
would
provide a workaround until patch 574750 is 
implemented and
also a fallback for people who still want to invoke
"jpython" rather than "jython".  If
the implementer decides
to remove the whole "py-toggle-shells" mechanism, 
then
this
patch would be a kind of substitute, but I am not 
advocating
that change.



                                

                                
Date: 2003-02-02 12:11
Sender: nnorwitz
Logged In: YES 
user_id=33168

How does this relate to patch 574750?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783259&group_id=86916

From noreply at sourceforge.net  Mon Aug  4 21:32:52 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:47:59 2003
Subject: [Python-mode] [ python-mode-Patches-783260 ] python-mode.el: make
	C-c - work correctly after C-c |
Message-ID: <E19jsZA-0003p2-00@sc8-sf-web1.sourceforge.net>

Patches item #783260, was opened at 2003-08-04 22:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783260&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode.el: make C-c - work correctly after C-c |

Initial Comment:
migrating #677838 from python project.

Original Submission:

If you are using python-mode in [X]Emacs and do 
 py-execute-region and get an exception, py-up-
exception 
 (C-c -) will go to the wrong line, because the line 
 number reported by Python is only relative to the 
start 
 of the region.

Followup comments:

Date: 2003-08-01 12:24
Sender: cgw
Logged In: YES 
user_id=7151

updated patch



                                

                                
Date: 2003-07-31 23:55
Sender: montanaro
Logged In: YES 
user_id=44345

Charles,  Any chance you can generate your diff 
against the
newest version of python-mode.el (something like 
4.38)?  I'm
having trouble applying the patch you submitted 
originally, and
my feeble manual attempts have so far not 
demonstrated that
the patch (as I applied it) fixes the problem.

Thx,

Skip



                                

                                
Date: 2003-01-31 10:37
Sender: cgw
Logged In: YES 
user_id=7151

I tried uploading the patch again,  and seem to have
succeeded this
time around.  It's probably not fair to blane SF, as I 
think
this was a case of pilot error.



                                

                                
Date: 2003-01-31 07:16
Sender: mwh
Logged In: YES 
user_id=6656

There's no patch attached... I think SF is subliminally
trying to push us into getting roundup ready to use.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783260&group_id=86916

From noreply at sourceforge.net  Mon Aug  4 21:35:27 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  4 23:48:00 2003
Subject: [Python-mode] [ python-mode-Patches-783262 ] python-mode
	py-execute-buffer bug
Message-ID: <E19jsbf-0003tW-00@sc8-sf-web1.sourceforge.net>

Patches item #783262, was opened at 2003-08-04 22:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783262&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode py-execute-buffer bug

Initial Comment:
migrated #779839 from python project.

Original Submission:

The rest of this report is a quote from Skip's message 
in 
 c.l.py. 
  
 Attached is Skip's tentative patch (which is likely 
 incorrect for Jython). 
  
 --------------------------------- 
     John> 1. Why do I get this in my minibuffer when 
I do 
     John> C-c C-c in a python-mode buffer containing 
the 
     John> following valid Python code? 
  
     John> Wrong type argument: sequencep, cpython 
  
 It looks like a bug in py-execute-region.  It sets the 
shell 
 variable like so: 
  
         (setq shell (or (py-choose-shell-by-shebang) 
 (py-choose-shell-by-import) py-which-shell)))) 
  
 which gives it the value (quote cpython).  Later on it 
tries 
 to concatenate it: 
  
       (let ((cmd (concat shell (if (string-equal 
 py-which-bufname "JPython") " -" "")))) 
  
 which fails because shell is not a string (strictly 
 speaking, a sequence) at that point.  I'm not sure 
what 
 the correct fix is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=783262&group_id=86916

From skip at pobox.com  Mon Aug  4 23:49:02 2003
From: skip at pobox.com (Skip Montanaro)
Date: Mon Aug  4 23:49:14 2003
Subject: [Python-mode] New place for python-mode bug reports and patches
Message-ID: <16175.10542.302239.792809@montanaro.dyndns.org>


As many of you are already aware, Barry Warsaw recently created a new
project on SourceForge to house the python-mode.el code which makes Emacs
and XEmacs so delightful to edit Python code.  I just completed migrating
all open bugs and patches which mention python-mode from the python project
to the new python-mode project.  In the future, please submit all bugs and
patches at

    http://sourceforge.net/projects/python-mode/

All new bugs and patches regarding python-mode should be submitted to the
new project.

There's also a mailing list, python-mode@python.org, to which you can
subscribe in the usual Pythonic fashion:

    http://mail.python.org/mailman/listinfo/python-mode

Skip

From noreply at sourceforge.net  Sat Aug  9 04:03:54 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  9 13:47:23 2003
Subject: [Python-mode] [ python-mode-Patches-785816 ] Py #567468: A
	different patch for python-mode vs gdb
Message-ID: <E19lQZm-0002Cy-00@sc8-sf-web2.sourceforge.net>

Patches item #785816, was opened at 2003-08-09 12:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=785816&group_id=86916

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py #567468: A different patch for python-mode vs gdb

Initial Comment:
This is from http://python.org/sf/567468:

 Patch 509975 fixes the conflict between gdb-mode and
python-mode by checking whether the current process is
a python process. My patch fixes it more simply, by
only clearing the overlay arrow if we were the ones who
set it.

I'd be happy with either patch. 

--------------------------------------------------------------

Date: 2002-07-16 18:53
Sender: bwarsaw
Logged In: YES 
user_id=12800

I've rejected 509975 because it doesn't play nice when
you're pdb tracking from the shell (see comments in
that patch).

I'm not sure this patch works correctly either, but for a
different reason: it doesn't actually work for me!

If I add "import pdb; pdb.set_trace()" to a file and
then
execute the file from the shell buffer, I see the overlay
arrow.  If I then switch to a gdb debugging a C program and
hit "next", the overlay arrow in the .py buffer
disappears.

This seems like a tricky problem and I don't have a good
solution, but I think I have to reject this patch too.

-----------------------------------------------------------------

Date: 2002-07-16 19:02
Sender: nobody
Logged In: NO 

The problem my patch was intended to fix is that currently
just loading python-mode.el (as happens by default
under Red
Hat 7.3) breaks gdb-mode.  With my patch, it works fine.

emacs only supports one overlay arrow at a time; if you hit
'next' in gdb, gdb-mode will set the overlay arrow, which
means that it will no longer be set in the python buffer. 
This may not be ideal behavior, but it's a limitation of
emacs, not a bug in my patch.

-----------------------------------------------------------------

Date: 2002-07-16 19:30
Sender: bwarsaw
Logged In: YES 
user_id=12800

Hmm, it must work differently in emacs than in XEmacs
(which
is what I use).  In a vanilla Emacs 21.2.1 I can't get the
overlay arrow to work even without python-mode.el
loaded, so
I'll have to take your word for it.

In XEmacs, I definitely do get two overlay arrows, one in
the C buffer and one in the python-mode buffer.  As I step
through the python program, the C arrow stays nicely
visible
and highlighted.  As I step through gdb though, the python
overlay arrow disappears.

Your patch makes no difference to me and I can't get
overlay
arrow working at all in Emacs, so I suppose the patch is
benign.  I'll reopen it but I'd like confirmation from some
other Emacs user that this fixes the problem in that
editor.
 Alternatively, maybe I should just apply it and worry
about
it if people complain.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=785816&group_id=86916

From postmaster at ulead.com.cn  Sat Aug 23 07:34:00 2003
From: postmaster at ulead.com.cn (Postmaster)
Date: Fri Aug 22 20:08:18 2003
Subject: [Python-mode] Undeliverable Mail
Message-ID: <10308230634.AA00952@ulead.com.cn>

User mailbox exceeds allowed size: info@ulead.com.cn


Original message follows.

Received: from THOMAS [217.236.121.66] by ulead.com.cn with ESMTP
  (SMTPD32-6.06) id AA351CC01BE; Sat, 23 Aug 2003 06:33:25 +0800
From: <python-mode@python.org>
To: <info@ulead.com.cn>
Subject: Re: Your application
Date: Sat, 23 Aug 2003 0:35:06 +0200
X-MailScanner: Found to be clean
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="_NextPart_000_0376C380"
Message-Id: <200308230633414.SM01212@THOMAS>

This is a multipart message in MIME format

--_NextPart_000_0376C380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please see the attached file for details.
--_NextPart_000_0376C380
Content-Type: application/octet-stream;
	name="document_9446.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="document_9446.pif"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAADToEjPl8EmnJfBJpyXwSacFN0onI3BJpx/3iyc7cEmnMHeNZyawSacl8Em
nJTBJpyXwSecBsEmnPXeNZyawSacf94tnI3BJpxSaWNol8EmnAAAAAAAAAAAAAAAAAAAAABQRQAA
TAEEAF2zPz8AAAAAAAAAAOAADwELAQYAAAAAAABwAAAAAAAA1usBAAAQAAAAYAEAAABAAAAQAAAA
AgAABAAAAAAAAAAEAAAAAAAAAAAAAgAAEAAAF/EBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAA
AAAAAAAAAAAAAOLrAQCcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfuwBAAgAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAgAC5zaHJpbmsAAFABAAAQAAAAxAAAABAAAAAAAAAAAAAAAAAAAEAAAMAu
c2hyaW5rAAAwAAAAYAEAABIAAADUAAAAAAAAAAAAAAAAAABAAADALnNocmluawAAQAAAAJABAAAS
AAAA5gAAAAAAAAAAAAAAAAAAQAAAwC5zaHJpbmsAADAAAADQAQAAIgAAAPgAAAAAAAAAAAAAAAAA
AEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

[message truncated]

From Olivier.Lefevre at biocrates.at  Sun Aug 24 22:59:10 2003
From: Olivier.Lefevre at biocrates.at (Olivier Lefevre)
Date: Sun Aug 24 16:14:55 2003
Subject: [Python-mode] Nasty bug
Message-ID: <sf49353f.092@t-c-c.at>

I was trying to use the last python-mode with NTEmacs 21.2. After loading
a *.py file, this is what happens if I click on one of pull-down menus from
the menu bar, e.g., File:

1/ I get
Debugger entered--Lisp error: (mark-inactive)
  signal(mark-inactive nil)
  mark()
2/ the menus can't be pulled downL it is as if they had disappeared.
3/ emacs can't be killed and has to be terminated from the Task Manager
4/ upon terminating, I get a popup window that says: "Error 109 when
     reading from stdin; Aborting"

This is pretty catastrophic...

-- O.L.