python-mode patch

python-mode patch

[Slawomir Nowaczyk]

Hello,

I would like to suggest the following patch for python-mode.

The intend is to make commands like python-send-buffer execute files
in the global namespace of the "main" script, not within namespace of
the "emacs" module.

An example: currently, if you run python-send-buffer in a buffer
containing "x=1", a python interpreter will open and execute the
assignment, but trying "print x" will fail. One needs to type,
instead, "print emacs.x". All functions, classes, variables etc.
defined in the buffer will end up in a namespace of "emacs" module.

After my patch, "print x" does work (note that I only have python
2.4.3 so I only tested there, but I think older versions should work
similarly).

For me, personally, this is a serious bug which makes python-mode
almost unusable. Did anybody actually liked the way it used to work?
It would be sufficiently easy to provide an option here, but I do not
think it makes sense.

**********************************************************************

--- etc/emacs.py        2006-02-06 00:44:47.000000000 +0100
+++ /c/Emacs/etc/emacs.py       2006-08-10 12:26:39.930859200 +0200
@@ -2,6 +2,7 @@

 # Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
 # Author: Dave Love <d.love@dl.ac.uk>
+# Modified: Slawomir Nowaczyk <slawek@cs.lth.se>

 # This file is part of GNU Emacs.

@@ -26,10 +27,12 @@

 def eexecfile (file):
     """Execute FILE and then remove it.
+    Make sure we execute the file within a namespace of __main__ script.
     If we get an exception, print a traceback with the top frame
-    (oursleves) excluded."""
+    (ourselves) excluded."""
     try:
-       try: execfile (file, globals (), globals ())
+       try:
+            execfile (file, __main__.__dict__)
        except:
            (type, value, tb) = sys.exc_info ()
            # Lose the stack frame for this location.
@@ -96,8 +99,8 @@
     sys.path[0] = dir
     try:
        try:
-           if globals().has_key(mod) and inspect.ismodule (eval (mod)):
-               reload(eval (mod))
+           if mod in sys.modules:
+               reload(sys.modules[mod])
            else:
                globals ()[mod] = __import__ (mod)
        except:

**********************************************************************

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Make it idiot-proof and someone will make a better idiot.

Re: python-mode patch

[Nick Roberts]

 >  # Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
 >  # Author: Dave Love <d.love@dl.ac.uk>
 > +# Modified: Slawomir Nowaczyk <slawek@cs.lth.se>

You don't need to add your name here, but if the patch is accepted you'll
need a ChangLog entry.

AFAICS this file and python.el appear to currently be unmaintained, so perhaps,
(after the release?) you would like to become the maintainer of these files.
It's just a thought on my part, Richard Stallman will make any decision.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: python-mode patch

[Slawomir Nowaczyk]

On Thu, 10 Aug 2006 23:22:35 +1200
Nick Roberts <nickrob@snap.net.nz> wrote:

#>  >  # Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
#>  >  # Author: Dave Love <d.love@dl.ac.uk>
#>  > +# Modified: Slawomir Nowaczyk <slawek@cs.lth.se>
#> 
#> You don't need to add your name here, but if the patch is accepted
#> you'll need a ChangLog entry.

Thank you. Like this?

**********************************************************************

--- etc/ChangeLog       2006-08-10 18:07:06.393926400 +0200
+++ /c/Emacs/etc/ChangeLog      2006-08-10 18:08:43.914153600 +0200
@@ -1,3 +1,8 @@
+2006-08-10  Slawomir Nowaczyk  <slawek@cs.lth.se>
+
+       * emacs.py: Make eexecfile execute the file within a namespace
+        of __main__ script.
+
 2006-08-09  Richard Stallman  <rms@gnu.org>

        * TUTORIAL: Don't say which side scroll bar is on.

**********************************************************************

#> AFAICS this file and python.el appear to currently be unmaintained,
#> so perhaps, (after the release?) you would like to become the
#> maintainer of these files. It's just a thought on my part, Richard
#> Stallman will make any decision.

Yes, I have been thinking about that, although I am not sure I have
enough time to maintain python-mode properly. On the other hand, I
*do* have a list of things I would like to improve...

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

To err is human, to moo bovine.

Re: python-mode patch

[Richard Stallman]

    You don't need to add your name here, but if the patch is accepted you'll
    need a ChangLog entry.

Looking at Slawomir's first message, it certainly sounds like an
improvement; but I do not know Python, so if there is some drawback, I
would not know.

Is there anyone here who knows Python and can advise me on whether to
install this patch?

Re: python-mode patch

[Slawomir Nowaczyk]

On Thu, 10 Aug 2006 16:19:58 -0400
Richard Stallman <rms@gnu.org> wrote:

#>     You don't need to add your name here, but if the patch is accepted you'll
#>     need a ChangLog entry.
#> 
#> Looking at Slawomir's first message, it certainly sounds like an
#> improvement; but I do not know Python, so if there is some drawback, I
#> would not know.
#> 
#> Is there anyone here who knows Python and can advise me on whether to
#> install this patch?

Apparently not :(

Anyway, it seems that essentially *nobody* is using python-mode from
CVS Emacs. There are two reasons, I imagine. First, it isn't all that
usable ATM -- there is quite a number of annoying quirks and things
that do not work as well as they should. Most of them seem to be minor
and not too difficult to fix, though, as the code is pretty clean.

The other reason, probably even important, is that there is another
python-mode, at http://sf.net/projects/python-mode

"Our" python-mode has one important advantage, however: it uses comint
for running Python interpreter, while the other one seems to have
ad-hoc code for talking to the Python. Therefore I do not think it is
a good idea to give up developing our version.

Taking it into account, I would like to become a maintainer of
python-mode. I would also like to try and fix as much as possible (due
to lack of my time it may not end up being all that much, though)
before the release. It should not cause any real problems since, as I
said, nobody appears to be using the mode currently.

And it is important to have a *working* mode for the release, if it is
to ever gain a reasonable user base.

One problem I have is about naming, as it is more than a little
confusing right now. "Our" mode is called python-mode, distributed in
file python.el, and uses commands starting with python-. The other
mode, originally developed by Tim Peters and maintained now (I think)
by Barry A. Warsaw is also called python-mode.

It would be good to have unambiguous way of talking about those modes.
Does anyone have a suggestion how to avoid confusion?

Would saying "GNU python-mode" make sense?

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Never let someone who says it cannot be done interrupt the person
who is doing it.

Re: python-mode patch

[Steven Huwig]

On Aug 20, 2006, at 3:53 PM, Slawomir Nowaczyk wrote:

> On Thu, 10 Aug 2006 16:19:58 -0400
> Richard Stallman <rms@gnu.org> wrote:
>
> #>     You don't need to add your name here, but if the patch is  
> accepted you'll
> #>     need a ChangLog entry.
> #>
> #> Looking at Slawomir's first message, it certainly sounds like an
> #> improvement; but I do not know Python, so if there is some  
> drawback, I
> #> would not know.
> #>
> #> Is there anyone here who knows Python and can advise me on  
> whether to
> #> install this patch?
>
> Apparently not :(

I tried the patch and it didn't seem to affect anything negatively.  I
have always assumed that there was some reason that the mode forced a
new namespace, but perhaps that is not the case.

>  Therefore I do not think it is
> a good idea to give up developing our version.

I do use python-mode from CVS Emacs exclusively when coding Python.
It works well enough as a basic mode, though the interactive portions
are primitive when compared to some other Emacs modes.

> Taking it into account, I would like to become a maintainer of
> python-mode. I would also like to try and fix as much as possible (due
> to lack of my time it may not end up being all that much, though)
> before the release. It should not cause any real problems since, as I
> said, nobody appears to be using the mode currently.

I am interested in testing and contributing fixes to python-mode as
well.  Some time ago I worked on some python-complete-symbol issues,
and a few weeks ago I spent some time trying to fix an issue with
commands that need to start the inferior process, before giving up for
lack of time.

> It would be good to have unambiguous way of talking about those modes.
> Does anyone have a suggestion how to avoid confusion?
>
> Would saying "GNU python-mode" make sense?

How about "Emacs 22 python-mode?"


Steven Huwig

Re: python-mode patch

[Edward O'Connor]

> Anyway, it seems that essentially *nobody* is using python-mode from
> CVS Emacs.

FWIW, I use it. I imagine approximately everyone who is using CVS Emacs
to write Python code is using it too.


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: python-mode patch

[Nick Roberts]

 > Anyway, it seems that essentially *nobody* is using python-mode from
 > CVS Emacs. 

I think it's only safe to assume no one is currently developing python-mode.

 >            There are two reasons, I imagine. First, it isn't all that
 > usable ATM -- there is quite a number of annoying quirks and things
 > that do not work as well as they should. Most of them seem to be minor
 > and not too difficult to fix, though, as the code is pretty clean.
 > 
 > The other reason, probably even important, is that there is another
 > python-mode, at http://sf.net/projects/python-mode

Doesn't this mode only work with XEmacs?

 > "Our" python-mode has one important advantage, however: it uses comint
 > for running Python interpreter, while the other one seems to have
 > ad-hoc code for talking to the Python. Therefore I do not think it is
 > a good idea to give up developing our version.

The other python-mode uses something called pdbtrack.  Can that be made to work
with Emacs?  (Perhaps Ken Mannheimer can elucidate).  I am interested in
improving pdb in gud.el but don't know enough about python.

 > Taking it into account, I would like to become a maintainer of
 > python-mode. I would also like to try and fix as much as possible (due
 > to lack of my time it may not end up being all that much, though)
 > before the release. It should not cause any real problems since, as I
 > said, nobody appears to be using the mode currently.

It will be a problem if you accidentally remove features that you are not
aware of.

 > And it is important to have a *working* mode for the release, if it is
 > to ever gain a reasonable user base.

Others seem to think it does work reasonably well.  Perhaps they can review
your proposed changes.

 > One problem I have is about naming, as it is more than a little
 > confusing right now. "Our" mode is called python-mode, distributed in
 > file python.el, and uses commands starting with python-. The other
 > mode, originally developed by Tim Peters and maintained now (I think)
 > by Barry A. Warsaw is also called python-mode.
 > 
 > It would be good to have unambiguous way of talking about those modes.
 > Does anyone have a suggestion how to avoid confusion?
 > 
 > Would saying "GNU python-mode" make sense?

On this mailing list if you say python-mode, we would assume you mean the
one in the CVS repository.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: python-mode patch

[Stefan Monnier]

> Would saying "GNU python-mode" make sense?

You can say "python.el".  But really I think it's only worth worrying about
it if you intend to make the two packages use different name spaces, so that
both can be loaded at the same time in a single Emacs session (like
perl-mode and cperl-mode).

So you could rename it to npython-mode where `n' stands for New ;-)
Or boa-mode (since viper-mode is already taken ;-)

But maybe it's not worth the trouble.


        Stefan "who happens to have just installed updates from Dave Love's
                upstream version"

Re: python-mode patch

[Piet van Oostrum]

>>>>> Edward O'Connor <hober0@gmail.com> (Ted) wrote:

>>> Anyway, it seems that essentially *nobody* is using python-mode from
>>> CVS Emacs.

>Ted> FWIW, I use it. I imagine approximately everyone who is using CVS Emacs
>Ted> to write Python code is using it too.

I use CVS Emacs with the other python mode. I didn't even know there is one
in CVS Emacs.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org

Re: python-mode patch

[Slawomir Nowaczyk]

On Mon, 21 Aug 2006 11:03:33 +0200
Piet van Oostrum <piet@cs.uu.nl> wrote:

#> >>>>> Edward O'Connor <hober0@gmail.com> (Ted) wrote:
#> 
#> >>> Anyway, it seems that essentially *nobody* is using python-mode from
#> >>> CVS Emacs.
#> 
#> Ted> FWIW, I use it. I imagine approximately everyone who is using CVS Emacs
#> Ted> to write Python code is using it too.
#> 
#> I use CVS Emacs with the other python mode. I didn't even know there is one
#> in CVS Emacs.

Yes, I have been using the other mode myself for quite some time
before I noticed python.el

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

The goal of Computer Science is to build something that will last at least
until we've finished building it.

Re: python-mode patch

[Slawomir Nowaczyk]

On Sun, 20 Aug 2006 18:33:43 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

#> > Would saying "GNU python-mode" make sense?
#> 
#> You can say "python.el".

I like it :)

#> But really I think it's only worth worrying about it if you intend
#> to make the two packages use different name spaces, so that both
#> can be loaded at the same time in a single Emacs session (like
#> perl-mode and cperl-mode).
#> 
#> So you could rename it to npython-mode where `n' stands for New ;-)
#> Or boa-mode (since viper-mode is already taken ;-)
#> 
#> But maybe it's not worth the trouble.

Probably not... Thanks for comments, nevertheless :)

#>         Stefan "who happens to have just installed updates from Dave Love's
#>                 upstream version"

Yes, I have seen it now :)

BTW, are you planning to make more changes to python.el? Or can I
start proposing more patches?

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Zawinski's Law: "Every program attempts to expand until it can read mail.
Those programs which cannot so expand are replaced by ones which can."

Re: python-mode patch

[Slawomir Nowaczyk]

On Mon, 21 Aug 2006 09:41:21 +1200
Nick Roberts <nickrob@snap.net.nz> wrote:

#>  > Anyway, it seems that essentially *nobody* is using python-mode from
#>  > CVS Emacs. 
#> 
#> I think it's only safe to assume no one is currently developing python-mode.

Yes, you are right... but by being a bit controversial I have finally
managed to get people to talk about python.el :)

#>  > The other reason, probably even important, is that there is another
#>  > python-mode, at http://sf.net/projects/python-mode
#> 
#> Doesn't this mode only work with XEmacs?

No. It is being advertised as "developed for XEmacs" or something like
that, but it works in Emacs just fine.

#>  > "Our" python-mode has one important advantage, however: it uses comint
#>  > for running Python interpreter, while the other one seems to have
#>  > ad-hoc code for talking to the Python. Therefore I do not think it is
#>  > a good idea to give up developing our version.
#> 
#> The other python-mode uses something called pdbtrack. Can that be
#> made to work with Emacs? (Perhaps Ken Mannheimer can elucidate). I
#> am interested in improving pdb in gud.el but don't know enough
#> about python.

I don't know, I do not use pdb much. But it is certainly worth looking
into.

#>  > Taking it into account, I would like to become a maintainer of
#>  > python-mode. I would also like to try and fix as much as possible (due
#>  > to lack of my time it may not end up being all that much, though)
#>  > before the release. It should not cause any real problems since, as I
#>  > said, nobody appears to be using the mode currently.
#> 
#> It will be a problem if you accidentally remove features that you are not
#> aware of.

Sure... I will try not to. And now that I know somebody is actually
using the mode, I can hope for more feedback.

#>  > And it is important to have a *working* mode for the release, if it is
#>  > to ever gain a reasonable user base.
#> 
#> Others seem to think it does work reasonably well.  Perhaps they can review
#> your proposed changes.

Hopefully. I will prepare a patch or two, then.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Lottery: A tax on people who don't understand statistics.

Re: python-mode patch

[Slawomir Nowaczyk]

On Sun, 20 Aug 2006 16:31:01 -0400
Steven Huwig <steven.huwig@gmail.com> wrote:

#> > #> Is there anyone here who knows Python and can advise me on
#> > #> whether to install this patch?
#> >
#> > Apparently not :(
#> 
#> I tried the patch and it didn't seem to affect anything negatively.
#> I have always assumed that there was some reason that the mode
#> forced a new namespace, but perhaps that is not the case.

I actually thought so as well... but was unable to figure out what the
reason could be. And I often play with the Python interpreter after
executing files, so having to type "emacs." every so often was quite
annoying.

#> > Therefore I do not think it is a good idea to give up developing
#> > our version.
#> 
#> I do use python-mode from CVS Emacs exclusively when coding Python.
#> It works well enough as a basic mode, though the interactive portions
#> are primitive when compared to some other Emacs modes.

Yes, I agree. For writing code, the mode is very good. I personally
use the interactive features quite a bit, and they indeed could use
some extra attention.

#> > Taking it into account, I would like to become a maintainer of
#> > python-mode. I would also like to try and fix as much as possible (due
#> > to lack of my time it may not end up being all that much, though)
#> > before the release. It should not cause any real problems since, as I
#> > said, nobody appears to be using the mode currently.
#> 
#> I am interested in testing and contributing fixes to python-mode as
#> well. 

Great!

#> > Would saying "GNU python-mode" make sense?
#> 
#> How about "Emacs 22 python-mode?"

I am not sure how unambiguous that would be... it will be pretty clear
until the release takes place, but probably not so much afterwards.
And the release is (probably) going to happen sooner or later ;)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

A phoneless cord: For people who like peace and quiet.

Re: python-mode patch

[Richard Stallman]

    Taking it into account, I would like to become a maintainer of
    python-mode. I would also like to try and fix as much as possible (due
    to lack of my time it may not end up being all that much, though)
    before the release. It should not cause any real problems since, as I
    said, nobody appears to be using the mode currently.

I would really appreciate that, but we'd need you to sign legal papers
before installing so much code from you.  I will send you the form
to get started.

    The other reason, probably even important, is that there is another
    python-mode, at http://sf.net/projects/python-mode

Would the authors of that program like to contribute?

    It would be good to have unambiguous way of talking about those modes.
    Does anyone have a suggestion how to avoid confusion?

    Would saying "GNU python-mode" make sense?

That would imply that the mode which is not installed
in Emacs is "the" python-mode, and ours plays second fiddle.

Re: python-mode patch

[Stefan Monnier]

> BTW, are you planning to make more changes to python.el? Or can I
> start proposing more patches?

I don't plan any more changes, no.


        Stefan

Re: python-mode patch

[Peter Lee]

>>>> Edward O'Connor writes:

    > FWIW, I use it. I imagine approximately everyone who is using CVS Emacs
    > to write Python code is using it too.

I don't use it, but then I only recently heard about it.  One annoying thing
about the built-in package is the creation of tmp buffers when using pdb and
stepping through the code via the interpreter.  The creation of the tmp buffer
is not a big deal (sourceforge python-mode does this too), but the CVS Emacs
version doesn't fontify it.  Other than that and the fact that "self" is not
fontified by default (py-pseudo-keyword-face for the other python-mode), I
didn't notice anything else... but I didn't use it very long... the
non-fontified tmp buffer is a non-starter for me.

Re: python-mode patch

[Ken Manheimer]

On 8/20/06, Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> wrote:
> On Thu, 10 Aug 2006 16:19:58 -0400
>
> Anyway, it seems that essentially *nobody* is using python-mode from
> CVS Emacs. There are two reasons, I imagine. First, it isn't all that
> usable ATM -- there is quite a number of annoying quirks and things
> that do not work as well as they should. Most of them seem to be minor
> and not too difficult to fix, though, as the code is pretty clean.
>
> The other reason, probably even important, is that there is another
> python-mode, at http://sf.net/projects/python-mode
>
> "Our" python-mode has one important advantage, however: it uses comint
> for running Python interpreter, while the other one seems to have
> ad-hoc code for talking to the Python. Therefore I do not think it is
> a good idea to give up developing our version.

the other python-mode, python-mode.el, has one feature that i would
love (and need) to see in any python-mode before switching.  (like
others, i didn't know about the python-mode that comes with emacs 22,
and i haven't tried it.)  i originally developed it as "pdbtrack", and
barry warsaw integrated it with  python-mode.el.

what it does is add a comint-output-filter-function which looks for
the prompts from python's interactive debugger, pdb.  when it sees
them it (and if configured for it), it pops up the file containing the
function/method in the focus of the python debugger, putting an
overlay arrow on the current line.  as the user debugs in the shell
buffer, pdbtrack continues to track the current file and line,
effectively giving a screen-oriented debugging session anytime the
python debugger is run from an interactive (comint) shell.  when the
user isn't using the debugger, pdbtrack does nothing.

this has a crucial advantage over gud-style debugging for interpreted
languages - you don't need to start the program from the debugger, or
use some elaborate process connection and prepartion of the running
program to connect to a running process.  instead of telling emacs to
debug something, emacs recognized when you're debugging something and
provides suitable support.

this is not only useful when you're running interactive sessions with
the python interpreter.  it's ideal when you run any python programs,
including servers.  when i am doing development with or of Zope (a
python-based web application server), i run the server non-detached in
a shell buffer.  that way, i can dynamically add tracing to code in
the running server, or in its special scripts, and when the server
hits those traces emacs presents me with a screen-oriented debugging
session.  for just about all layers of Zope operation.   *effortless*.

the reason i mention this in such detail is because (1) it's
invaluable, (2) it was less than 150 lines of emacs lisp code,
including copious comments, docstrings, etc, (3) i think this is a
much much more promising approach than the insanely elaborate gud.el
approach - not to mention lame, for intrepreted programs, at least,
and i believe for compiled programs, as well.

150 lines of code (apparently 156, now) only gets the very basic
pdb-session file/line tracking.  you type debugging commands at the
interpreter, there are no provisions for setting breakpoints in a
screen-oriented manner, etc - but file/line tracking is 9/10 of the
value of a screen-oriented debugger, for me, and the interpreter is
quite manageable for the other 1/10.  i'd prefer if this approach were
extended to do the other stuff , but at least would like to see it
incorporated with python.el's python-mode.

if you're interested in scoping it out, look for variables and
functions that contain the string pdbtrack".  i suspect most of it can
be used exactly as is.

at 150 lines of code, and since i wrote the original, i would be happy
to sign papers for it.

> Taking it into account, I would like to become a maintainer of
> python-mode. I would also like to try and fix as much as possible (due
> to lack of my time it may not end up being all that much, though)
> before the release. It should not cause any real problems since, as I
> said, nobody appears to be using the mode currently.
>
> And it is important to have a *working* mode for the release, if it is
> to ever gain a reasonable user base.
>
> One problem I have is about naming, as it is more than a little
> confusing right now. "Our" mode is called python-mode, distributed in
> file python.el, and uses commands starting with python-. The other
> mode, originally developed by Tim Peters and maintained now (I think)
> by Barry A. Warsaw is also called python-mode.
>
> It would be good to have unambiguous way of talking about those modes.
> Does anyone have a suggestion how to avoid confusion?
>
> Would saying "GNU python-mode" make sense?
>
> --
>  Best wishes,
>    Slawomir Nowaczyk
>      ( slawomir.nowaczyk.847@student.lu.se )
>
> Never let someone who says it cannot be done interrupt the person
> who is doing it.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>


-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

Re: python-mode patch

[Stefan Monnier]

> stepping through the code via the interpreter.  The creation of the tmp buffer
> is not a big deal (sourceforge python-mode does this too), but the CVS Emacs
> version doesn't fontify it.  Other than that and the fact that "self" is not

I have no idea what you're talking about.
Can you give us some step-by-step explanation of what you're thinking of?


        Stefan

Re: python-mode patch

[Peter Lee]

>>>> Stefan Monnier writes:

    > Can you give us some step-by-step explanation of what you're thinking of?

create test.py:
---------------
import pdb

pdb.set_trace()

a = 1
b = 2

print a + b

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

from test.py buffer create interactive shell: C-c C-!
switch back to test.py: C-x o
run it: C-c C-c
switch back to interactive shell: C-x o
step: n

test.py reverts to /usr/tmp/python-11756sPY and loses fontification.

sf.net's python-mode also reverts to a tmp buffer but does not lose
fontification.

Ideally there would be no tmp buffer at all, it would use the real file... and
if not loaded would load it.  I can't tell you how many times I've edited a tmp
buffer... really maddening.  Ironically editing the tmp buffer by mistake is
less likely with CVS python-mode because it doesn't fontify it.  But if I had to
choose, I'd go with fontification.

Also, it would also be nice to have a binding that would both start the shell
and execute the current buffer rather than the 4 commands needed currently.

Re: python-mode patch

[Slawomir Nowaczyk]

On Tue, 22 Aug 2006 14:40:15 -0500
Peter Lee <pete.a.lee@gmail.com> wrote:

#> from test.py buffer create interactive shell: C-c C-!

C-c C-! is undefined in python-mode I use... and the "shell" terminology
is not used in our mode, only in the other one. But I assume you mean 
python-switch-to-python command.

#> switch back to test.py: C-x o
#> run it: C-c C-c
#> switch back to interactive shell: C-x o
#> step: n

#> test.py reverts to /usr/tmp/python-11756sPY

Nothing reverts for me... I have a strong impression you are not using
python-mode from CVS, as this mode doesn't do anything special about
pdb AFAICT (the pdb tracking feature is only present in the other mode).

#> and loses fontification.

I would imagine the reason for that is that "python-11756sPY" doesn't
look like name of python file, so python-mode doesn't get turned on.
Try "C-h m" and maybe play with auto-mode-alist.

#> Ideally there would be no tmp buffer at all, it would use the real
#> file... and if not loaded would load it.

Yes, I imagine it would be the right way to implement that.

#> Also, it would also be nice to have a binding that would both start the shell
#> and execute the current buffer rather than the 4 commands needed currently.

Actually, C-c C-c works... the only thing is it doesn't show Inferior
Python by default, so you would need to switch to *Python* buffer
manually. Still, that's only two commands, not 4 :)

But I am thinking about improving that.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

The PROPER way to handle HTML postings is to cancel the article, then
hire a hitman to kill the poster, his wife and kids, and fuck his dog
and smash his computer into little bits. Anything more is just
extremism. -- Paul Tomblin

Re: python-mode patch

[Peter Lee]

>>>> Slawomir Nowaczyk writes:

    > C-c C-! is undefined in python-mode I use... and the "shell" terminology
    > is not used in our mode, only in the other one. But I assume you mean 
    > python-switch-to-python command.

Yes you are right, somehow I was in a bizarre state where the other python-mode
was getting picked up although I had removed it from load-path.

    > Nothing reverts for me... I have a strong impression you are not using
    > python-mode from CVS, as this mode doesn't do anything special about
    > pdb AFAICT (the pdb tracking feature is only present in the other mode).

Right, it doesn't revert now... that's nice.  I will start using this going forward.

    > Actually, C-c C-c works... the only thing is it doesn't show Inferior
    > Python by default, so you would need to switch to *Python* buffer
    > manually. Still, that's only two commands, not 4 :)

It does work as you say and 2 is def. better than 4.

Can "self" be made a keyword?

Thanks for clearing the rest up.

Re: python-mode patch

[Nick Roberts]

 > the other python-mode, python-mode.el, has one feature that i would
 > love (and need) to see in any python-mode before switching.  (like
 > others, i didn't know about the python-mode that comes with emacs 22,
 > and i haven't tried it.)  i originally developed it as "pdbtrack", and
 > barry warsaw integrated it with  python-mode.el.

I think it would be good to add this especially as it is so few lines
of code.

 > what it does is add a comint-output-filter-function which looks for
 > the prompts from python's interactive debugger, pdb.

Yes.  I think these hooks should be local as they interfere with other
comint derived buffers like shell, GUD etc.

 >...
 > 150 lines of code (apparently 156, now) only gets the very basic
 > pdb-session file/line tracking.  you type debugging commands at the
 > interpreter, there are no provisions for setting breakpoints in a
 > screen-oriented manner, etc - but file/line tracking is 9/10 of the
 > value of a screen-oriented debugger, for me, and the interpreter is
 > quite manageable for the other 1/10.  i'd prefer if this approach were
 > extended to do the other stuff , but at least would like to see it
 > incorporated with python.el's python-mode.

It seems to me that most Python developers prefer it to pdb in gud.el but
I see no reason why they shouldn't work alongside one another.

 > if you're interested in scoping it out, look for variables and
 > functions that contain the string pdbtrack".  i suspect most of it can
 > be used exactly as is.
 > 
 > at 150 lines of code, and since i wrote the original, i would be happy
 > to sign papers for it.

Presumably you've already signed papers for Emacs as you have contributed
allout.el.

I find the PDB string in the mode-line too intrusive.  If it's needed, perhaps
it could be a real minor-mode in the py-shell buffer.

I would also add a sentinel so e.g the overlay arrow is no longer displayed
if the py-shell buffer is killed.

How about the changes below? (this is from FC5, I don't know what version
of python-mode that corresponds to).

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** /usr/share/emacs/site-lisp/python-mode.el	2006-03-08 01:12:21.000000000 +1300
--- /home/nickrob/lisp/python-mode.el	2006-08-23 20:08:47.000000000 +1200
***************
*** 271,281 ****
    :group 'python)
  (make-variable-buffer-local 'py-pdbtrack-do-tracking-p)
  
- (defcustom py-pdbtrack-minor-mode-string " PDB"
-   "*String to use in the minor mode list when pdbtrack is enabled."
-   :type 'string
-   :group 'python)
- 
  ;; Not customizable
  (defvar py-master-file nil
    "If non-nil, execute the named file instead of the buffer's file.
--- 271,276 ----
***************
*** 1298,1308 ****
      (switch-to-buffer-other-window
       (apply 'make-comint py-which-bufname py-which-shell nil args))
      (make-local-variable 'comint-prompt-regexp)
      (setq comint-prompt-regexp "^>>> \\|^[.][.][.] \\|^(pdb) ")
      (add-hook 'comint-output-filter-functions
! 	      'py-comint-output-filter-function)
      ;; pdbtrack
!     (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file)
      (setq py-pdbtrack-do-tracking-p t)
      (set-syntax-table py-mode-syntax-table)
      (use-local-map py-shell-map)
--- 1293,1305 ----
      (switch-to-buffer-other-window
       (apply 'make-comint py-which-bufname py-which-shell nil args))
      (make-local-variable 'comint-prompt-regexp)
+     (set-process-sentinel (get-buffer-process (current-buffer)) 'py-sentinel)
      (setq comint-prompt-regexp "^>>> \\|^[.][.][.] \\|^(pdb) ")
      (add-hook 'comint-output-filter-functions
! 	      'py-comint-output-filter-function nil t)
      ;; pdbtrack
!     (add-hook 'comint-output-filter-functions
! 	      'py-pdbtrack-track-stack-file nil t)
      (setq py-pdbtrack-do-tracking-p t)
      (set-syntax-table py-mode-syntax-table)
      (use-local-map py-shell-map)
***************
*** 3245,3258 ****
  
  ;; arrange to kill temp files when Emacs exists
  (add-hook 'kill-emacs-hook 'py-kill-emacs-hook)
- (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file)
  
! ;; Add a designator to the minor mode strings
! (or (assq 'py-pdbtrack-minor-mode-string minor-mode-alist)
!     (push '(py-pdbtrack-is-tracking-p py-pdbtrack-minor-mode-string)
! 	  minor-mode-alist))
  
- 
- \f
  (provide 'python-mode)
  ;;; python-mode.el ends here
--- 3242,3250 ----
  
  ;; arrange to kill temp files when Emacs exists
  (add-hook 'kill-emacs-hook 'py-kill-emacs-hook)
  
! (defun py-sentinel (proc msg)
!   (setq overlay-arrow-position nil))
  
  (provide 'python-mode)
  ;;; python-mode.el ends here

Re: python-mode patch

[Ken Manheimer]

On 8/23/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > the other python-mode, python-mode.el, has one feature that i would
>  > love (and need) to see in any python-mode before switching.  (like
>  > others, i didn't know about the python-mode that comes with emacs 22,
>  > and i haven't tried it.)  i originally developed it as "pdbtrack", and
>  > barry warsaw integrated it with  python-mode.el.
>
> I think it would be good to add this especially as it is so few lines
> of code.

particularly when useful...

>  > what it does is add a comint-output-filter-function which looks for
>  > the prompts from python's interactive debugger, pdb.
>
> Yes.  I think these hooks should be local as they interfere with other
> comint derived buffers like shell, GUD etc.

agreed - didn't know about qualifying hooks as local, at the time.
(they're incredibly useful.)

>  > 150 lines of code (apparently 156, now) only gets the very basic
>  > pdb-session file/line tracking.  you type debugging commands at the
>  > interpreter, there are no provisions for setting breakpoints in a
>  > screen-oriented manner, etc - but file/line tracking is 9/10 of the
>  > value of a screen-oriented debugger, for me, and the interpreter is
>  > quite manageable for the other 1/10.  i'd prefer if this approach were
>  > extended to do the other stuff , but at least would like to see it
>  > incorporated with python.el's python-mode.
>
> It seems to me that most Python developers prefer it to pdb in gud.el but
> I see no reason why they shouldn't work alongside one another.

i don't disagree at all about enabling pdbtrack and gud to coexist.
i've seen some discussion about revamping gud (after the emacs 22
release), and have wanted to alert those concerned to a substantially
different approach, which migh yield better results - or might not,
but is worth considering.  however gud's job is done, enabling them to
coexist is good.

(i think for many python developers, me included, pdb in gud is not an
option, because it means leaving the environment at the point where
you want/need to do the debugging and somehow recreating it in a new
gud / python session.  i mention this because this quandry is not
obvious until you're actually in the situation, but the situation is
the common one for an interaction-oriented interpreted environment
like python's.  ironically, it's much like lisp in this way - hence,
emacs has edebug, debug-on-error, edebug-on-error, etc, so you can
start to debug when the bugs occur.  i suspect the pdbtrack approach
would be eminently suited for inferior lisp processes, as well...)

>  > if you're interested in scoping it out, look for variables and
>  > functions that contain the string pdbtrack".  i suspect most of it can
>  > be used exactly as is.
>  >
>  > at 150 lines of code, and since i wrote the original, i would be happy
>  > to sign papers for it.
>
> Presumably you've already signed papers for Emacs as you have contributed
> allout.el.

i don't recall whether the signoff i've done applies to any
contributions - i think i had to sign another for icomplete, for
instance.

> I find the PDB string in the mode-line too intrusive.  If it's needed, perhaps
> it could be a real minor-mode in the py-shell buffer.

i haven't noticed that in a while (and haven't had the opportunity to
write python for a while), will take a look.

> I would also add a sentinel so e.g the overlay arrow is no longer displayed
> if the py-shell buffer is killed.

that sounds good.

> How about the changes below? (this is from FC5, I don't know what version
> of python-mode that corresponds to).

these are good suggestions - i'll look at them soon, see about
incorporating them into python-mode.el, and including them in the
suggestions if someone works it all into python.el.

tnx!

-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

> *** /usr/share/emacs/site-lisp/python-mode.el   2006-03-08 01:12:21.000000000 +1300
> --- /home/nickrob/lisp/python-mode.el   2006-08-23 20:08:47.000000000 +1200
> ***************
> *** 271,281 ****
>     :group 'python)
>   (make-variable-buffer-local 'py-pdbtrack-do-tracking-p)
>
> - (defcustom py-pdbtrack-minor-mode-string " PDB"
> -   "*String to use in the minor mode list when pdbtrack is enabled."
> -   :type 'string
> -   :group 'python)
> -
>   ;; Not customizable
>   (defvar py-master-file nil
>     "If non-nil, execute the named file instead of the buffer's file.
> --- 271,276 ----
> ***************
> *** 1298,1308 ****
>       (switch-to-buffer-other-window
>        (apply 'make-comint py-which-bufname py-which-shell nil args))
>       (make-local-variable 'comint-prompt-regexp)
>       (setq comint-prompt-regexp "^>>> \\|^[.][.][.] \\|^(pdb) ")
>       (add-hook 'comint-output-filter-functions
> !             'py-comint-output-filter-function)
>       ;; pdbtrack
> !     (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file)
>       (setq py-pdbtrack-do-tracking-p t)
>       (set-syntax-table py-mode-syntax-table)
>       (use-local-map py-shell-map)
> --- 1293,1305 ----
>       (switch-to-buffer-other-window
>        (apply 'make-comint py-which-bufname py-which-shell nil args))
>       (make-local-variable 'comint-prompt-regexp)
> +     (set-process-sentinel (get-buffer-process (current-buffer)) 'py-sentinel)
>       (setq comint-prompt-regexp "^>>> \\|^[.][.][.] \\|^(pdb) ")
>       (add-hook 'comint-output-filter-functions
> !             'py-comint-output-filter-function nil t)
>       ;; pdbtrack
> !     (add-hook 'comint-output-filter-functions
> !             'py-pdbtrack-track-stack-file nil t)
>       (setq py-pdbtrack-do-tracking-p t)
>       (set-syntax-table py-mode-syntax-table)
>       (use-local-map py-shell-map)
> ***************
> *** 3245,3258 ****
>
>   ;; arrange to kill temp files when Emacs exists
>   (add-hook 'kill-emacs-hook 'py-kill-emacs-hook)
> - (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file)
>
> ! ;; Add a designator to the minor mode strings
> ! (or (assq 'py-pdbtrack-minor-mode-string minor-mode-alist)
> !     (push '(py-pdbtrack-is-tracking-p py-pdbtrack-minor-mode-string)
> !         minor-mode-alist))
>
> -
> -
>   (provide 'python-mode)
>   ;;; python-mode.el ends here
> --- 3242,3250 ----
>
>   ;; arrange to kill temp files when Emacs exists
>   (add-hook 'kill-emacs-hook 'py-kill-emacs-hook)
>
> ! (defun py-sentinel (proc msg)
> !   (setq overlay-arrow-position nil))
>
>   (provide 'python-mode)
>   ;;; python-mode.el ends here

Re: python-mode patch

[Slawomir Nowaczyk]

On Mon, 21 Aug 2006 07:13:11 -0400
Richard Stallman <rms@gnu.org> wrote:

#>     The other reason, probably even important, is that there is another
#>     python-mode, at http://sf.net/projects/python-mode
#> 
#> Would the authors of that program like to contribute?

I am not sure, but I may try asking them... unless somebody who knows
them would like to do that?

Sourceforge lists the following people as developers: Barry A. Warsaw,
Edward Loper, Kurt B. Kaiser, Ken Manheimer and Skip Montanaro.

#>     It would be good to have unambiguous way of talking about those modes.
#>     Does anyone have a suggestion how to avoid confusion?
#> 
#>     Would saying "GNU python-mode" make sense?
#> 
#> That would imply that the mode which is not installed in Emacs is
#> "the" python-mode, and ours plays second fiddle.

Well, that's certainly true -- at least at the moment...

Also, it might be worthwhile to help distinguishing the modes at least
by having different indicator in the modeline -- currently both use
"Python" so it is even nontrivial for users to determine which one are
they actually running...

Does Emacs have any guidelines as to how modeline indicator should
look like? Is there something we could use instead of "Python"?
"Python-Mode"? "PYTHON"? "python"? Something else?

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Avoid metaphors like the plague.

Re: python-mode patch

[Slawomir Nowaczyk]

On Tue, 22 Aug 2006 15:31:33 -0500
Peter Lee <pete.a.lee@gmail.com> wrote:

#> Can "self" be made a keyword?

I hope so :)

Here is a patch.

**********************************************************************

--- m:/EmacsCVS/EmacsCVS/lisp/progmodes/python.el       2006-08-22 19:49:58.809940800 +0200
+++ c:/Emacs/lisp/progmodes/python.el   2006-08-23 22:07:21.844835200 +0200
@@ -94,7 +94,9 @@
             "import" "in" "is" "lambda" "not" "or" "pass" "print"
             "raise" "return" "try" "while" "yield"
             ;; Future keywords
-            "as" "None")
+            "as" "None"
+             ;; Not real keywords, but close enough to be fontified as such
+             "self" "True" "False")
         symbol-end)
     ;; Definitions
     (,(rx symbol-start (group "class") (1+ space) (group (1+ (or word ?_))))

**********************************************************************

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

In 10 minutes, a hurricane releases more energy than all of the world's
nuclear weapons combined.

Re: python-mode patch

[Slawomir Nowaczyk]

On Mon, 21 Aug 2006 14:27:58 -0400
Ken Manheimer <ken.manheimer@gmail.com> wrote:

#> if you're interested in scoping it out, look for variables and
#> functions that contain the string pdbtrack".  i suspect most of it can
#> be used exactly as is.
#> 
#> at 150 lines of code, and since i wrote the original, i would be happy
#> to sign papers for it.

Sounds great... Just in case, do you have the latest version of your
own code somewhere? If/when you sign papers, that is definitely
something we can use, while the code which currently resides in
python-mode.el might have been changed by other people as well, so I
presume we would need to get assignments from everybody who worked on
that.

Which isn't necessarily a bad thing, I guess it would be worthwhile to
try and seize more code from python-mode.el, but I do not know if it's
authors would be interested in signing papers for Emacs.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

If it wasn't for C, we would be using BASI, PASAL, LIPPER and OBOL!

Re: python-mode patch

[Nick Roberts]

 > #> if you're interested in scoping it out, look for variables and
 > #> functions that contain the string pdbtrack".  i suspect most of it can
 > #> be used exactly as is.
 > #> 
 > #> at 150 lines of code, and since i wrote the original, i would be happy
 > #> to sign papers for it.
 > 
 > Sounds great... Just in case, do you have the latest version of your
 > own code somewhere? If/when you sign papers, that is definitely
 > something we can use, while the code which currently resides in
 > python-mode.el might have been changed by other people as well, so I
 > presume we would need to get assignments from everybody who worked on
 > that.

Here's a first attempt at scoping it out.  I don't know if everything I added
was necessary but it comes in at about 440 lines of extra code.  I've also
changed the py namespace to python.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** python.el	21 Aug 2006 11:35:42 +1200	1.41
--- python.el	25 Aug 2006 09:59:47 +1200	
***************
*** 196,201 ****
--- 196,202 ----
      (define-key map "\C-c<" 'python-shift-left)
      (define-key map "\C-c>" 'python-shift-right)
      (define-key map "\C-c\C-k" 'python-mark-block)
+     (define-key map "\C-c\C-d" 'python-pdbtrack-toggle-stack-tracking)
      (define-key map "\C-c\C-n" 'python-next-statement)
      (define-key map "\C-c\C-p" 'python-previous-statement)
      (define-key map "\C-c\C-u" 'python-beginning-of-block)
***************
*** 273,281 ****
  ;; eric has items including: (un)indent, (un)comment, restart script,
  ;; run script, debug script; also things for profiling, unit testing.
  
  (defvar python-mode-syntax-table
    (let ((table (make-syntax-table)))
!     ;; Give punctuation syntax to ASCII that normally has symbol
      ;; syntax or has word syntax and isn't a letter.
      (let ((symbol (string-to-syntax "_"))
  	  (sst (standard-syntax-table)))
--- 274,290 ----
  ;; eric has items including: (un)indent, (un)comment, restart script,
  ;; run script, debug script; also things for profiling, unit testing.
  
+ (defvar python-shell-map
+   (let ((map (copy-keymap comint-mode-map)))
+     (define-key map [tab]   'tab-to-tab-stop)
+     (define-key map "\C-c-" 'py-up-exception)
+     (define-key map "\C-c=" 'py-down-exception)
+     map)
+   "Keymap used in *Python* shell buffers.")
+ 
  (defvar python-mode-syntax-table
    (let ((table (make-syntax-table)))
!     ;; Give punctuAtion syntax to ASCII that normally has symbol
      ;; syntax or has word syntax and isn't a letter.
      (let ((symbol (string-to-syntax "_"))
  	  (sst (standard-syntax-table)))
***************
*** 436,441 ****
--- 445,511 ----
    :group 'python
    :type 'integer)
  
+ 
+ (defcustom python-default-interpreter 'cpython
+   "*Which Python interpreter is used by default.
+ The value for this variable can be either `cpython' or `jpython'.
+ 
+ When the value is `cpython', the variables `python-python-command' and
+ `python-python-command-args' are consulted to determine the interpreter
+ and arguments to use.
+ 
+ When the value is `jpython', the variables `python-jpython-command' and
+ `python-jpython-command-args' are consulted to determine the interpreter
+ and arguments to use.
+ 
+ Note that this variable is consulted only the first time that a Python
+ mode buffer is visited during an Emacs session.  After that, use
+ \\[python-toggle-shells] to change the interpreter shell."
+   :type '(choice (const :tag "Python (a.k.a. CPython)" cpython)
+ 		 (const :tag "JPython" jpython))
+   :group 'python)
+ 
+ (defcustom python-python-command-args '("-i")
+   "*List of string arguments to be used when starting a Python shell."
+   :type '(repeat string)
+   :group 'python)
+ 
+ ;; for toggling between CPython and JPython
+ (defvar python-which-shell nil)
+ (defvar python-which-args  python-python-command-args)
+ (defvar python-which-bufname "Python")
+ (make-variable-buffer-local 'python-which-shell)
+ (make-variable-buffer-local 'python-which-args)
+ (make-variable-buffer-local 'python-which-bufname)
+ 
+ (defcustom python-pdbtrack-do-tracking-p t
+   "*Controls whether the pdbtrack feature is enabled or not.
+ When non-nil, pdbtrack is enabled in all comint-based buffers,
+ e.g. shell buffers and the *Python* buffer.  When using pdb to debug a
+ Python program, pdbtrack notices the pdb prompt and displays the
+ source file and line that the program is stopped at, much the same way
+ as gud-mode does for debugging C programs with gdb."
+   :type 'boolean
+   :group 'python)
+ (make-variable-buffer-local 'python-pdbtrack-do-tracking-p)
+ 
+ ;; Bind python-file-queue before installing the kill-emacs-hook.
+ (defvar python-file-queue nil
+   "Queue of Python temp files awaiting execution.
+ Currently-active file is at the head of the list.")
+ 
+ (defvar python-pdbtrack-is-tracking-p nil)
+ 
+ (defconst python-pdbtrack-stack-entry-regexp
+   "> \\([^(]+\\)(\\([0-9]+\\))[?a-zA-Z0-9_]+()"
+   "Regular expression pdbtrack uses to find a stack trace entry.")
+ 
+ (defconst python-pdbtrack-input-prompt "\n[(<]?pdb[>)]? "
+   "Regular expression pdbtrack uses to recognize a pdb prompt.")
+ 
+ (defconst python-pdbtrack-track-range 10000
+   "Max number of characters from end of buffer to search for stack entry.")
+ 
  (defun python-guess-indent ()
    "Guess step for indentation of current buffer.
  Set `python-indent' locally to the value guessed."
***************
*** 2077,2083 ****
    (condition-case data
        (unless (fboundp 'brm-rename)
  	(pymacs-load "bikeemacs" "brm-") ; first line of normal recipe
! 	(let ((py-mode-map (make-sparse-keymap)) ; it assumes this
  	      (features (cons 'python-mode features)) ; and requires this
  	      menu)
  	  (brm-init)			; second line of normal recipe
--- 2147,2153 ----
    (condition-case data
        (unless (fboundp 'brm-rename)
  	(pymacs-load "bikeemacs" "brm-") ; first line of normal recipe
! 	(let ((python-mode-map (make-sparse-keymap)) ; it assumes this
  	      (features (cons 'python-mode features)) ; and requires this
  	      menu)
  	  (brm-init)			; second line of normal recipe
***************
*** 2247,2252 ****
--- 2317,2692 ----
    :group 'python
    (set (make-local-variable 'python-command) python-jython-command))
  
+ \f
+ 
+ ;; pdbtrack features
+ 
+ (defsubst python-point (position)
+   "Returns the value of point at certain commonly referenced POSITIONs.
+ POSITION can be one of the following symbols:
+ 
+   bol  -- beginning of line
+   eol  -- end of line
+   bod  -- beginning of def or class
+   eod  -- end of def or class
+   bob  -- beginning of buffer
+   eob  -- end of buffer
+   boi  -- back to indentation
+   bos  -- beginning of statement
+ 
+ This function does not modify point or mark."
+   (let ((here (point)))
+     (cond
+      ((eq position 'bol) (beginning-of-line))
+      ((eq position 'eol) (end-of-line))
+      ((eq position 'bod) (python-beginning-of-def-or-class))
+      ((eq position 'eod) (python-end-of-def-or-class))
+      ;; Kind of funny, I know, but useful for python-up-exception.
+      ((eq position 'bob) (beginning-of-buffer))
+      ((eq position 'eob) (end-of-buffer))
+      ((eq position 'boi) (back-to-indentation))
+      ((eq position 'bos) (python-goto-initial-line))
+      (t (error "Unknown buffer position requested: %s" position)))
+     (prog1
+ 	(point)
+       (goto-char here))))
+ 
+ (defun python-end-of-def-or-class (&optional class count)
+   "Move point beyond end of `def' or `class' body.
+ 
+ By default, looks for an appropriate `def'.  If you supply a prefix
+ arg, looks for a `class' instead.  The docs below assume the `def'
+ case; just substitute `class' for `def' for the other case.
+ Programmatically, if CLASS is `either', then moves to either `class'
+ or `def'.
+ 
+ When second optional argument is given programmatically, move to the
+ COUNTth end of `def'.
+ 
+ If point is in a `def' statement already, this is the `def' we use.
+ 
+ Else, if the `def' found by `\\[python-beginning-of-def-or-class]'
+ contains the statement you started on, that's the `def' we use.
+ 
+ Otherwise, we search forward for the closest following `def', and use that.
+ 
+ If a `def' can be found by these rules, point is moved to the start of
+ the line immediately following the `def' block, and the position of the
+ start of the `def' is returned.
+ 
+ Else point is moved to the end of the buffer, and nil is returned.
+ 
+ Note that doing this command repeatedly will take you closer to the
+ end of the buffer each time.
+ 
+ To mark the current `def', see `\\[python-mark-def-or-class]'."
+   (interactive "P")			; raw prefix arg
+   (if (and count (/= count 1))
+       (python-beginning-of-def-or-class (- 1 count)))
+   (let ((start (progn (python-goto-initial-line) (point)))
+ 	(which (cond ((eq class 'either) "\\(class\\|def\\)")
+ 		     (class "class")
+ 		     (t "def")))
+ 	(state 'not-found))
+     ;; move point to start of appropriate def/class
+     (if (looking-at (concat "[ \t]*" which "\\>")) ; already on one
+ 	(setq state 'at-beginning)
+       ;; else see if python-beginning-of-def-or-class hits container
+       (if (and (python-beginning-of-def-or-class class)
+ 	       (progn (python-goto-beyond-block)
+ 		      (> (point) start)))
+ 	  (setq state 'at-end)
+ 	;; else search forward
+ 	(goto-char start)
+ 	(if (re-search-forward (concat "^[ \t]*" which "\\>") nil 'move)
+ 	    (progn (setq state 'at-beginning)
+ 		   (beginning-of-line)))))
+     (cond
+      ((eq state 'at-beginning) (python-goto-beyond-block) t)
+      ((eq state 'at-end) t)
+      ((eq state 'not-found) nil)
+      (t (error "Internal error in `python-end-of-def-or-class'")))))
+ 
+ (defun python-beginning-of-def-or-class (&optional class count)
+   "Move point to start of `def' or `class'.
+ 
+ Searches back for the closest preceding `def'.  If you supply a prefix
+ arg, looks for a `class' instead.  The docs below assume the `def'
+ case; just substitute `class' for `def' for the other case.
+ Programmatically, if CLASS is `either', then moves to either `class'
+ or `def'.
+ 
+ When second optional argument is given programmatically, move to the
+ COUNTth start of `def'.
+ 
+ If point is in a `def' statement already, and after the `d', simply
+ moves point to the start of the statement.
+ 
+ Otherwise (i.e. when point is not in a `def' statement, or at or
+ before the `d' of a `def' statement), searches for the closest
+ preceding `def' statement, and leaves point at its start.  If no such
+ statement can be found, leaves point at the start of the buffer.
+ 
+ Returns t iff a `def' statement is found by these rules.
+ 
+ Note that doing this command repeatedly will take you closer to the
+ start of the buffer each time.
+ 
+ To mark the current `def', see `\\[python-mark-def-or-class]'."
+   (interactive "P")			; raw prefix arg
+   (setq count (or count 1))
+   (let ((at-or-before-p (<= (current-column) (current-indentation)))
+ 	(start-of-line (goto-char (python-point 'bol)))
+ 	(start-of-stmt (goto-char (python-point 'bos)))
+ 	(start-re (cond ((eq class 'either) "^[ \t]*\\(class\\|def\\)\\>")
+ 			(class "^[ \t]*class\\>")
+ 			(t "^[ \t]*def\\>")))
+ 	)
+     ;; searching backward
+     (if (and (< 0 count)
+ 	     (or (/= start-of-stmt start-of-line)
+ 		 (not at-or-before-p)))
+ 	(end-of-line))
+     ;; search forward
+     (if (and (> 0 count)
+ 	     (zerop (current-column))
+ 	     (looking-at start-re))
+ 	(end-of-line))
+     (if (re-search-backward start-re nil 'move count)
+ 	(goto-char (match-beginning 0)))))
+ 
+ (defun python-goto-initial-line ()
+   "Go to the initial line of the current statement.
+ Usually this is the line we're on, but if we're on the 2nd or
+ following lines of a continuation block, we need to go up to the first
+ line of the block."
+   ;; Tricky: We want to avoid quadratic-time behavior for long
+   ;; continued blocks, whether of the backslash or open-bracket
+   ;; varieties, or a mix of the two.  The following manages to do that
+   ;; in the usual cases.
+   ;;
+   ;; Also, if we're sitting inside a triple quoted string, this will
+   ;; drop us at the line that begins the string.
+   (let (open-bracket-pos)
+     (while (python-continuation-line-p)
+       (beginning-of-line)
+       (if (python-backslash-continuation-line-p)
+ 	  (while (python-backslash-continuation-line-p)
+ 	    (forward-line -1))
+ 	;; else zip out of nested brackets/braces/parens
+ 	(while (setq open-bracket-pos (python-nesting-level))
+ 	  (goto-char open-bracket-pos)))))
+   (beginning-of-line))
+ 
+ (defun python-comint-output-filter-function (string)
+   "Watch output for Python prompt and exec next file waiting in queue.
+ This function is appropriate for `comint-output-filter-functions'."
+   ;; TBD: this should probably use split-string
+   (when (and (or (string-equal string ">>> ")
+ 		 (and (>= (length string) 5)
+ 		      (string-equal (substring string -5) "\n>>> ")))
+ 	     python-file-queue)
+     (python-safe (delete-file (car python-file-queue)))
+     (setq python-file-queue (cdr python-file-queue))
+     (if python-file-queue
+ 	(let ((pyproc (get-buffer-process (current-buffer))))
+ 	  (python-execute-file pyproc (car python-file-queue))))))
+ 
+ (defun python-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 (python-point 'bol) (current-buffer))
+ 	 (setq python-pdbtrack-is-tracking-p t))
+ 	(python-pdbtrack-is-tracking-p
+ 	 (setq overlay-arrow-position nil)
+ 	 (setq python-pdbtrack-is-tracking-p nil))
+ 	))
+ 
+ (defun python-pdbtrack-track-stack-file (text)
+   "Show the file indicated by the pdb stack entry line, in a separate window.
+ 
+ Activity is disabled if the buffer-local variable
+ `python-pdbtrack-do-tracking-p' is nil.
+ 
+ We depend on the pdb input prompt matching `python-pdbtrack-input-prompt'
+ at the beginning of the line."
+   ;; Instead of trying to piece things together from partial text
+   ;; (which can be almost useless depending on Emacs version), we
+   ;; monitor to the point where we have the next pdb prompt, and then
+   ;; check all text from comint-last-input-end to process-mark.
+   ;;
+   ;; KLM: It might be nice to provide an optional override, so this
+   ;; routine could be fed debugger output strings as the text
+   ;; argument, for deliberate application elsewhere.
+   ;;
+   ;; KLM: We're very conservative about clearing the overlay arrow, to
+   ;; minimize residue.  This means, for instance, that executing other
+   ;; pdb commands wipes out the highlight.
+   (let* ((origbuf (current-buffer))
+ 	 (currproc (get-buffer-process origbuf)))
+     (if (not (and currproc python-pdbtrack-do-tracking-p))
+         (python-pdbtrack-overlay-arrow nil)
+       (let* (;(origdir default-directory)
+              (procmark (process-mark currproc))
+              (block (buffer-substring (max comint-last-input-end
+                                            (- procmark
+                                               python-pdbtrack-track-range))
+                                       procmark))
+              fname lineno)
+         (if (not (string-match (concat python-pdbtrack-input-prompt "$") block))
+             (python-pdbtrack-overlay-arrow nil)
+           (if (not (string-match
+                     (concat ".*" python-pdbtrack-stack-entry-regexp ".*")
+                     block))
+               (python-pdbtrack-overlay-arrow nil)
+             (setq fname (match-string 1 block)
+                   lineno (match-string 2 block))
+             (if (file-exists-p fname)
+                 (progn
+                   (find-file-other-window fname)
+                   (goto-line (string-to-int lineno))
+                   (message "pdbtrack: line %s, file %s" lineno fname)
+                   (python-pdbtrack-overlay-arrow t)
+                   (pop-to-buffer origbuf t) )
+               (if (= (elt fname 0) ?\<)
+                   (message "pdbtrack: (Non-file source: '%s')" fname)
+                 (message "pdbtrack: File not found: %s" fname))
+               )))))))
+ 
+ (defun python-toggle-shells (arg)
+   "Toggles between the CPython and JPython shells.
+ 
+ With positive argument ARG (interactively \\[universal-argument]),
+ uses the CPython shell, with negative ARG uses the JPython shell, and
+ with a zero argument, toggles the shell.
+ 
+ Programmatically, ARG can also be one of the symbols `cpython' or
+ `jpython', equivalent to positive arg and negative arg respectively."
+   (interactive "P")
+   ;; default is to toggle
+   (if (null arg)
+       (setq arg 0))
+   ;; preprocess arg
+   (cond
+    ((equal arg 0)
+     ;; toggle
+     (if (string-equal python-which-bufname "Python")
+ 	(setq arg -1)
+       (setq arg 1)))
+    ((equal arg 'cpython) (setq arg 1))
+    ((equal arg 'jpython) (setq arg -1)))
+   (let (msg)
+     (cond
+      ((< 0 arg)
+       ;; set to CPython
+       (setq python-which-shell python-python-command
+ 	    python-which-args python-python-command-args
+ 	    python-which-bufname "Python"
+ 	    msg "CPython"
+ 	    mode-name "Python"))
+      ((> 0 arg)
+       (setq python-which-shell python-jpython-command
+ 	    python-which-args python-jpython-command-args
+ 	    python-which-bufname "JPython"
+ 	    msg "JPython"
+ 	    mode-name "JPython"))
+      )
+     (message "Using the %s shell" msg)
+     (setq python-output-buffer (format "*%s Output*" python-which-bufname))))
+ 
+ ;;;###autoload
+ (defun python-shell (&optional argprompt)
+   "Start an interactive Python interpreter in another window.
+ This is like Shell mode, except that Python is running in the window
+ instead of a shell.  See the `Interactive Shell' and `Shell Mode'
+ sections of the Emacs manual for details, especially for the key
+ bindings active in the `*Python*' buffer.
+ 
+ With optional \\[universal-argument], the user is prompted for the
+ flags to pass to the Python interpreter.  This has no effect when this
+ command is used to switch to an existing process, only when a new
+ process is started.  If you use this, you will probably want to ensure
+ that the current arguments are retained (they will be included in the
+ prompt).  This argument is ignored when this function is called
+ programmatically, or when running in Emacs 19.34 or older.
+ 
+ Note: You can toggle between using the CPython interpreter and the
+ JPython interpreter by hitting \\[python-toggle-shells].  This toggles
+ buffer local variables which control whether all your subshell
+ interactions happen to the `*JPython*' or `*Python*' buffers (the
+ latter is the name used for the CPython buffer).
+ 
+ Warning: Don't use an interactive Python if you change sys.ps1 or
+ sys.ps2 from their default values, or if you're running code that
+ prints `>>> ' or `... ' at the start of a line.  `python-mode' can't
+ distinguish your output from Python's output, and assumes that `>>> '
+ at the start of a line is a prompt from Python.  Similarly, the Emacs
+ Shell mode code assumes that both `>>> ' and `... ' at the start of a
+ line are Python prompts.  Bad things can happen if you fool either
+ mode.
+ 
+ Warning:  If you do any editing *in* the process buffer *while* the
+ buffer is accepting output from Python, do NOT attempt to `undo' the
+ changes.  Some of the output (nowhere near the parts you changed!) may
+ be lost if you do.  This appears to be an Emacs bug, an unfortunate
+ interaction between undo and process filters; the same problem exists in
+ non-Python process buffers using the default (Emacs-supplied) process
+ filter."
+   (interactive "P")
+   ;; Set the default shell if not already set
+   (when (null python-which-shell)
+     (python-toggle-shells python-default-interpreter))
+   (let ((args python-which-args))
+     (when (and argprompt
+ 	       (interactive-p)
+ 	       (fboundp 'split-string))
+       ;; TBD: Perhaps force "-i" in the final list?
+       (setq args (split-string
+ 		  (read-string (concat python-which-bufname
+ 				       " arguments: ")
+ 			       (concat
+ 				(mapconcat 'identity python-which-args " ") " ")
+ 			       ))))
+     (switch-to-buffer-other-window
+      (apply 'make-comint python-which-bufname python-which-shell nil args))
+     (make-local-variable 'comint-prompt-regexp)
+     (set-process-sentinel (get-buffer-process (current-buffer)) 'python-sentinel)
+     (setq comint-prompt-regexp "^>>> \\|^[.][.][.] \\|^(pdb) ")
+     (add-hook 'comint-output-filter-functions
+ 	      'python-comint-output-filter-function nil t)
+     ;; pdbtrack
+     (add-hook 'comint-output-filter-functions
+ 	      'python-pdbtrack-track-stack-file nil t)
+     (setq python-pdbtrack-do-tracking-p t)
+     (set-syntax-table python-mode-syntax-table)
+     (use-local-map python-shell-map)))
+ 
+ (defun python-pdbtrack-toggle-stack-tracking (arg)
+   (interactive "P")
+   (if (not (get-buffer-process (current-buffer)))
+       (error "No process associated with buffer '%s'" (current-buffer)))
+   ;; missing or 0 is toggle, >0 turn on, <0 turn off
+   (if (or (not arg)
+ 	  (zerop (setq arg (prefix-numeric-value arg))))
+       (setq python-pdbtrack-do-tracking-p (not python-pdbtrack-do-tracking-p))
+     (setq python-pdbtrack-do-tracking-p (> arg 0)))
+   (message "%sabled Python's pdbtrack"
+            (if python-pdbtrack-do-tracking-p "En" "Dis")))
+ 
+ (defun turn-on-pdbtrack ()
+   (interactive)
+   (python-pdbtrack-toggle-stack-tracking 1))
+ 
+ (defun turn-off-pdbtrack ()
+   (interactive)
+   (python-pdbtrack-toggle-stack-tracking 0))
+ 
+ (defun python-sentinel (proc msg)
+   (setq overlay-arrow-position nil))
+ 
  (provide 'python)
  (provide 'python-21)
  ;; arch-tag: 6fce1d99-a704-4de9-ba19-c6e4912b0554

Re: python-mode patch

[Richard Stallman]

    Sourceforge lists the following people as developers: Barry A. Warsaw,
    Edward Loper, Kurt B. Kaiser, Ken Manheimer and Skip Montanaro.

Barry Warsaw and Ken Manheimer have both contributed to Emacs already.
For respect, we should ask them about this anyway, but I expect they
will be glad to cooperate.  So it is a matter of asking the other
three.

However, before doing that, the first step is to identify whatever
code from their file we would actually like to use.

Re: python-mode patch

[Richard Stallman]

    Also, it might be worthwhile to help distinguishing the modes at least
    by having different indicator in the modeline -- currently both use
    "Python" so it is even nontrivial for users to determine which one are
    they actually running...

I don't see a need for this.  It is not normally for both of them to
be installed.

Any given user will be running the one from Emacs, unless his machine
has the other one installed.

Re: python-mode patch

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Sourceforge lists the following people as developers: Barry
>     A. Warsaw, Edward Loper, Kurt B. Kaiser, Ken Manheimer and Skip
>     Montanaro.
>
> Barry Warsaw and Ken Manheimer have both contributed to Emacs already.
> For respect, we should ask them about this anyway, but I expect they
> will be glad to cooperate.

I don't think it is just for respect: a copyright assignment covers
stuff that a person _intends_ to contribute, not anything we can get
our hands on in some manner.

People might decide for some reason that they don't want to see some
code of theirs in Emacs proper.

> So it is a matter of asking the other three.

I think it would be proper asking all of them, and mentioning that
_if_ all of them are ok with that, only assignments from those who
have not given them previously are required.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: python-mode patch

[Nick Roberts]

 >     Sourceforge lists the following people as developers: Barry A. Warsaw,
 >     Edward Loper, Kurt B. Kaiser, Ken Manheimer and Skip Montanaro.
 > 
 > Barry Warsaw and Ken Manheimer have both contributed to Emacs already.
 > For respect, we should ask them about this anyway, but I expect they
 > will be glad to cooperate.  So it is a matter of asking the other
 > three.

Ken Manheimer has aleady stated that he is willing.  Presumably signing papers
for Emacs means giving copyright for offered contributions to the FSF,
not that anyone can take any code you have written and include it in Emacs.
In that respect, Barry Warsaw still needs to give his permission for
python-mode.el, doesn't he?

 > However, before doing that, the first step is to identify whatever
 > code from their file we would actually like to use.

I think there is agreement that pdbtrack is a desirable feature and the
patch I scoped out was about 440 lines.  Since you will probably insist
that all authors are contacted for this feature alone, why not contact
them now?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: python-mode patch

[Slawomir Nowaczyk]

On Fri, 25 Aug 2006 03:43:42 -0400
Richard Stallman <rms@gnu.org> wrote:

#>     Also, it might be worthwhile to help distinguishing the modes at least
#>     by having different indicator in the modeline -- currently both use
#>     "Python" so it is even nontrivial for users to determine which one are
#>     they actually running...
#> 
#> I don't see a need for this.

OK, I do not have very strong opinion about that... the reason I asked
is because we have already had somebody confused about which mode was
he actually running -- on emacs-devel. I just assumed that the likelihood
of confusion in other societies is even larger.

#> It is not normally for both of them to be installed.

I am not so sure about that...

#> Any given user will be running the one from Emacs, unless his machine
#> has the other one installed.

Any user who have been writing Python code before he switched to CVS
Emacs, as well as any user who uses both CVS and 21.3 versions of
Emacs, is likely to have both modes installed.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

I dream of being Bugs Bunny, but when I wake up,
I'm Daffy Duck or Wile E. Coyote. 

Re: python-mode patch

[Richard Stallman]

    Ken Manheimer has aleady stated that he is willing.  Presumably signing papers
    for Emacs means giving copyright for offered contributions to the FSF,
    not that anyone can take any code you have written and include it in Emacs.
    In that respect, Barry Warsaw still needs to give his permission for
    python-mode.el, doesn't he?

I see he has signed papers for other files he contributed to Emacs,
but not this one.  So you're right, we do need to ask him for papers
for this.

Ken Manheimer has signed an assignment for all Emacs changes, so he
just has to affirm that we should count this as an Emacs change.

      Since you will probably insist
    that all authors are contacted for this feature alone, 

Yes and no.  If a certain author did not contribute to that code, we
don't need to ask him for papers for it.

							   why not contact
    them now?

We may as well as them now.  Would someone like to do so?

Re: python-mode patch

[Stefan Monnier]

> #> Can "self" be made a keyword?
> I hope so :)
> Here is a patch.

Thank you, installed.


        Stefan

Re: python-mode patch

[Nick Roberts]

Richard Stallman writes:
 >     Ken Manheimer has aleady stated that he is willing.  Presumably signing
 >     papers for Emacs means giving copyright for offered contributions to the
 >     FSF, not that anyone can take any code you have written and include it
 >     in Emacs.  In that respect, Barry Warsaw still needs to give his
 >     permission for python-mode.el, doesn't he?
 > 
 > I see he has signed papers for other files he contributed to Emacs,
 > but not this one.  So you're right, we do need to ask him for papers
 > for this.
 > 
 > Ken Manheimer has signed an assignment for all Emacs changes, so he
 > just has to affirm that we should count this as an Emacs change.
 > 
 >       Since you will probably insist
 >     that all authors are contacted for this feature alone, 
 > 
 > Yes and no.  If a certain author did not contribute to that code, we
 > don't need to ask him for papers for it.
 > 
 > 							   why not contact
 >     them now?
 > 
 > We may as well as them now.  Would someone like to do so?

I still have a python-mode patch for pdbtrack.  Have we got any further
collecting signatures?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: python-mode patch

[Stefan Monnier]

> I still have a python-mode patch for pdbtrack.

Any reason not to install it?


        Setfan

Re: python-mode patch

[Ken Manheimer]

On 9/26/06, Nick Roberts <nickrob@snap.net.nz> wrote:
> Richard Stallman writes:
>  >     Ken Manheimer has aleady stated that he is willing.  Presumably signing
>  >     papers for Emacs means giving copyright for offered contributions to the
>  >     FSF, not that anyone can take any code you have written and include it
>  >     in Emacs.  In that respect, Barry Warsaw still needs to give his
>  >     permission for python-mode.el, doesn't he?
>  >
>  > I see he has signed papers for other files he contributed to Emacs,
>  > but not this one.  So you're right, we do need to ask him for papers
>  > for this.
>  >
>  > Ken Manheimer has signed an assignment for all Emacs changes, so he
>  > just has to affirm that we should count this as an Emacs change.

in case it's in question, i affirm that we should count this as an
emacs change.  i am happy to have pdb tracking in python.el, even more
happy since i didn't have to spend time porting it.  let me know
specifically if there's anything more in the way of confirmation that
you need.

>  >       Since you will probably insist
>  >     that all authors are contacted for this feature alone,
>  >
>  > Yes and no.  If a certain author did not contribute to that code, we
>  > don't need to ask him for papers for it.
>  >
>  >                                                         why not contact
>  >     them now?
>  >
>  > We may as well as them now.  Would someone like to do so?
>
> I still have a python-mode patch for pdbtrack.  Have we got any further
> collecting signatures?

-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

Re: python-mode patch

[Nick Roberts]

 > > I still have a python-mode patch for pdbtrack.
 > 
 > Any reason not to install it?

Well the essence of the patch
(http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00930.html) is based
Ken's work but the file from which it comes has other authors.  One aim of
getting other signatures was to include other features from python-mode.el
but I am unable judge whether this patch needs them.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: python-mode patch

[Richard Stallman]

I sent mail to Barry Warsaw requesting papers for this.