Re: [Python-mode] python-mode.el checkout

[Andreas Röhler]

Am Mittwoch, 7. Mai 2008 02:19 schrieben Sie:
> 
> Andreas> could someone tell me please, how to check out last
> Andreas> python-mode.el?
> 
> Something like this:
> 
> svn co 
https://python-mode.svn.sourceforge.net/svnroot/python-mode/trunk/python-mode 
python-mode
> 
> If you'd like checkin privileges, send me your SF id.

I'll look for that for next time.

> There's also a mailing list:
> 
Inscribed.

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

Herewith the patch

Introduced an additional check for being not-in-string:

(not (numberp (nth 3 state)))


Thanks

Andreas Röhler
diff -u -b /old/python-mode.el /new/python-mode.el
--- /old/python-mode.el	2008-05-07 08:05:55.0 +0200
+++ /new/python-mode.el	2008-05-08 15:28:35.0 +0200
@@ -3522,7 +3522,7 @@
 		  (setq searching nil)	; search is done either way
 		  (setq state (parse-partial-sexp start
 		  (match-beginning 0)))
-		  (setq answer (not (nth 4 state)
+		  (setq answer (and (not (numberp (nth 3 state)))(not (nth 4 state))
 	  ;; search failed: couldn't find another interesting colon
 	  (setq searching nil)))
   answer)))

Diff finished.  Thu May  8 15:29:02 2008
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python-mode.el checkout

[Andreas Röhler]

Am Freitag, 9. Mai 2008 03:14 schrieben Sie:
> 
> Andreas> Herewith the patch
> 
> Andreas> Introduced an additional check for being not-in-string:
> 
> Andreas> (not (numberp (nth 3 state)))
> 
> Andreas> Thanks
> 
> Andreas> Andreas Röhler
> Andreas> diff -u -b /old/python-mode.el /new/python-mode.el
> Andreas> --- /old/python-mode.el  2008-05-07 08:05:55.0 +0200
> Andreas> +++ /new/python-mode.el  2008-05-08 15:28:35.0 +0200
> Andreas> @@ -3522,7 +3522,7 @@
> Andreas>(setq searching nil)  ; search is done either 
> way
> Andreas>(setq state (parse-partial-sexp start
> Andreas>
> (match-beginning 0)))
> Andreas> -  (setq answer (not (nth 4 state)
> Andreas> +  (setq answer (and (not (numberp (nth 3 
> state)))(not (nth 4 
state))
> Andreas>;; search failed: couldn't find another interesting 
> colon
> Andreas>(setq searching nil)))
> Andreas>answer)))
> 
> Exactly what problem does that additional check solve? 

[ ... ]

Bug reported by David Hemmingsson at 

http://mail.python.org/pipermail/python-mode/2003-August/02.html:

Thanks for a nice emacs mode!

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

filen.write("\n")
filen.write("a:link{ text-decoration:none; color:#ff}\n")
filen.write("a:visited\{ text-decoration:none\; color:#ff\}\n")
filen.write("a:active\{ text-decoration:none\; color:#ff\} 
\n")  

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Moved to Launchpad and Bazaar

[Andreas Röhler]

Hi Barry,

I asked for join with my adress already registered at launchpad: 
[EMAIL PROTECTED]

Baazar seems interesting, the rather childish atmosphere of launchpad I hope 
to bear for Emacs's sake. :)

Thanks for python-mode BTW.

Andreas Röhler


Am Freitag, 9. Mai 2008 17:23 schrieb Barry Warsaw:
> As previously threatened, er, promised, I've finally moved the
> official python-mode.el source code repository to Launchpad, to be
> managed under the Bazaar revision control system.  I cannot remove the
> old SourceForge Subversion repository, but I've disabled all write
> access to it and removed the link from the SF page.
> 
> Since the repo was pretty simple, I believe I've preserved all the
> history, but let me know if anything looks weird.
> 
> The project page is here:
> 
> https://launchpad.net/python-mode
> 
> Click on the Code tab if you want to learn how to get read-only branch.
> 
> I've also created a new team called python-mode-devs.  Members of this
> team will have write access to the main branch, although of course
> anybody can push their own personal branches of python-mode.  Right
> now I'm the only member of the team, but if you want write access to
> python-mode's bzr, go to
> 
> https://launchpad.net/~python-mode-devs
> 
> and click on Join.  This is a moderated team (since it controls write
> access), but when I see your request, if I know who you are ,
> I'll approve it.
> 
> Cheers and let me know if you have any questions.
> -Barry
> 
> P.S. Eventually, I want to import the SF tracker into Launchpad, but
> that's not automated yet.  I know the guy to bug about it and as soon
> as he does the Mailman tracker I'll get him to do the python-mode
> tracker. :)
> 
> P.P.S. Ken, I think this will make it easier to work on the eventual
> XEmacs/FSFmacs merge of the mode.
> 
> ___
> Python-mode mailing list
> Python-mode@python.org
> http://mail.python.org/mailman/listinfo/python-mode
> 
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [CEDET-devel] python

[Andreas Röhler]

Eric M. Ludlam wrote:
>>>> Vladimir Kazanov  seems to think that:
>>>> 
>>> Probably off topic, but just in case you are not aware of, *ropemacs*
>>> supports Python very well under Emacs.
>>>
>>> Cheers,
>>> poppyer
>>>   
>> Well... Could you redirect me to a more suitable mailing list then?
>>
>> I do have and actively use pymacs/ropemacs, but wouldn`t it be better
>> to use a single
>> system for various languages? Consistency is important, after all.
>> 
>   [ ... ]
>
> Hi,
>
>   I'm not that familiar with Python or pymacs/ropemacs.  If these
> tools provide some sort of file parsing, tag searching feature, then
> they could plug into the back-end of the semantic parsing/searching
> tools.
>
>   The ideal is that any tool that can supply tagging information would
> plug into CEDET.  Then anyone who has a cool completion UI idea would
> implement it on top of CEDET.  In that way the users would get the
> best of the tagging and their favorite completion UI styles instead of
> having something slightly different for every language they use.
>
>   If someone wants to tackle a project of improving the python support
> I'd be happy to help.
>
> Eric
>
>   
Hi Eric, hi Vladimir, hi all,

I'm taking part in developing python-mode.el, which has a mailing-list
at its own, (see cc)
its run by Barry Warsaw.

python-mode.el is designed for all Emacsen.

We take interest in any python-related topic with Emacs.

So please feel free to cc or adress us with your questions,
even if not python-mode.el specific.

Thanks

Andreas Röhler

--
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] [Fwd: Re: python setup ?]

[Andreas Röhler]

Hi Barry,

as some questions about Emacs and python are raised, I forward that here.

Tend to delete all files beside python-mode.el from my branch.

Good idea? Agreed?


Andreas
--- Begin Message ---
Andreas Röhler  writes:

> Richard Riley wrote:
>> Andreas Röhler  writes:
>>
>>   
>>> Richard Riley wrote:
>>> 
>>>> Richard Riley  writes:
>>>>
>>>>   
>>>>   
>>>>> Xavier Maillard  writes:
>>>>>
>>>>> 
>>>>> 
>>>>>> Hi,
>>>>>>
>>>>>> I am starting to do some work with python. I am looking for
>>>>>> options/setups to introduce into my .emacs file to have the best
>>>>>> experience possible with this scripting language.
>>>>>>
>>>>>> Where should I start ?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>  Xavier
>>>>>>   
>>>>>>   
>>>>> I played with some python options last year and it was, unfortunately,
>>>>> rather messy. There were some conflicts between packages any python
>>>>> versions. For what its worth, the following was working back when with
>>>>> emacs 23:
>>>>>
>>>>> http://www.emacswiki.org/emacs/PythonMode#toc11
>>>>> http://richardriley.net/projects/emacs/dotprogramming#sec-1.3
>>>>>
>>>>> It includes autocompletion from autocomplete using pysmell. Another
>>>>> possible integration for eclim and the eclipse engine I would have
>>>>> thought.
>>>>>
>>>>> The iPython bit is commented out - I can't remember why off the top of
>>>>> my head.  The pymacs git repository seems dead too unfortunately. 
>>>>>
>>>>> The python-mode used is 5.1.0.
>>>>>
>>>>>
>>>>> 
>>>>> 
>>>> Just to follow up, I re-enabled the ipython bit and it worked fine. I
>>>> had ipython 0.9.1 installed.
>>>>
>>>> The python config (for Linux) is then done in
>>>> ~/.ipython/ipy_user_conf.py
>>>>
>>>>   
>>>>   
>>> Hi,
>>>
>>> I've changed python-mode a little bit.
>>> Purpose was to make movements a little bit easier,
>>> more predictible.
>>>
>>> Comments welcome.
>>>
>>> BTW have a look at pydb from Rocky Bernstein, if not done already.
>>>
>>> Andreas
>>> 
>>
>> I see you have a pycomplete. Nicholaj Schum has jus put together a
>> company mode backend for pysmell. How does pycomplete compare to
>> pysmell?
>>   
>
> Thats part of the package kept by Barry Warsaw.  Made a branch from it,
> but changed only python-mode.el.
>
> I'm not sure to keep this files in my branch or not.
>
> Nonetheless, thanks for your question. I shall have a look at it and try
> an answer next days.
>
> BTW as more things are at stake as python-mode.el, what would you think
> about an archiv
> emacs-python, where all the stuff to edit python-code with emacs is
> collected?

To be honest, my feeling is that the last thing anyone needs is yet
another python place. The wiki is already a mess of questions and
answers and mode specific difficulties. Tie that in with emacs 23/22 and
ipython or not, the numerous ways you can do python completion etc, it
needs to be simplified not extended.

Thanks for the heads up about pydb btw, nice.

>
> For me Launchpad seems perfect for such a thing with its email- and
> bug-report-integration.
>
> There we could discuss the probably best emacs-python configuration -
> which will change,
> if someone brings up new things.

I think the emacs wiki is best for this stuff purely because its "there"
and there are numerous utilities to integrate emacs with emacs wiki
pages. Just keep links to relevant pages.

You might be right : point the wiki to launchpad and remove all the out
of date stuff. What do others think?

>
>
> Andreas
>
>
>
>>
>>   
>>> --
>>> http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files
>>> https://code.launchpad.net/s-x-emacs-werkstatt/
>>>
>>>
>>>
>>>
>>> 
>>
>>   
>
>
>

-- 

--- End Message ---
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Fwd: Re: python setup ?]

[Andreas Röhler]

Barry Warsaw wrote:
> On Apr 27, 2009, at 8:41 AM, Andreas Röhler wrote:
>
>> as some questions about Emacs and python are raised, I forward that
>> here.
>>
>> Tend to delete all files beside python-mode.el from my branch.
>>
>> Good idea? Agreed?
>
> I generally leave the other files there, but only use python-mode.el.
>
> -Barry
>

The point is, I don't really understand until now, if I should branch
these files into my repo or not.

Sure, you should keep it. Or better to say:  we should keep a general
repo for python-tools written so far.
OTOH, while developing certain files, we must not clone the whole repo.
Or must we
because of zar bazaars will?

Cheers

Andreas




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] [Fwd: Re: python setup ?]

[Andreas Röhler]

Hi Thierry,

thanks for the help. Forwarded it to python-mode@python.org and will
see, if we get it into the archive at launchpad. (BTW  seeing no
contradiction towards emacs-wiki, just different tools /possibilities.
Vive la difference!)


Andreas
--- Begin Message ---
Hi Richard,

Richard Riley  writes:

> Andreas Röhler  writes:
>
>> Richard Riley wrote:
>>> Andreas Röhler  writes:
>>>
>>>   
>>>> Richard Riley wrote:
>>>> 
>>>>> Richard Riley  writes:
>>>>>
>>>>>   
>>>>>   
>>>>>> Xavier Maillard  writes:
>>>>>>
>>>>>> 
>>>>>> 
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am starting to do some work with python. I am looking for
>>>>>>> options/setups to introduce into my .emacs file to have the best
>>>>>>> experience possible with this scripting language.
>>>>>>>
>>>>>>> Where should I start ?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Xavier
>>>>>>>   
>>>>>>>   
>>>>>> I played with some python options last year and it was, unfortunately,
>>>>>> rather messy. There were some conflicts between packages any python
>>>>>> versions. For what its worth, the following was working back when with
>>>>>> emacs 23:
>>>>>>
>>>>>> http://www.emacswiki.org/emacs/PythonMode#toc11
>>>>>> http://richardriley.net/projects/emacs/dotprogramming#sec-1.3
>>>>>>
>>>>>> It includes autocompletion from autocomplete using pysmell. Another
>>>>>> possible integration for eclim and the eclipse engine I would have
>>>>>> thought.
>>>>>>
>>>>>> The iPython bit is commented out - I can't remember why off the top of
>>>>>> my head.  The pymacs git repository seems dead too unfortunately. 
>>>>>>
>>>>>> The python-mode used is 5.1.0.
>>>>>>
>>>>>>
>>>>>> 
>>>>>> 
>>>>> Just to follow up, I re-enabled the ipython bit and it worked fine. I
>>>>> had ipython 0.9.1 installed.
>>>>>
>>>>> The python config (for Linux) is then done in
>>>>> ~/.ipython/ipy_user_conf.py
>>>>>
>>>>>   
>>>>>   
>>>> Hi,
>>>>
>>>> I've changed python-mode a little bit.
>>>> Purpose was to make movements a little bit easier,
>>>> more predictible.
>>>>
>>>> Comments welcome.
>>>>
>>>> BTW have a look at pydb from Rocky Bernstein, if not done already.
>>>>
>>>> Andreas
>>>> 
>>>
>>> I see you have a pycomplete. Nicholaj Schum has jus put together a
>>> company mode backend for pysmell. How does pycomplete compare to
>>> pysmell?

I use this actually:
http://article.gmane.org/gmane.emacs.help/50837/match=pycomplete

That is the only pycomplete that work fine for me, it's really nice, the
author should put it on emacswiki or send it as a patch for python-mode
package.
 
The pycomplete that come with python-mode doesn't work for me.

I don't know pysmell, and i don't use company, auto-complete etc...

>>
>> Thats part of the package kept by Barry Warsaw.  Made a branch from it,
>> but changed only python-mode.el.
>>
>> I'm not sure to keep this files in my branch or not.
>>
>> Nonetheless, thanks for your question. I shall have a look at it and try
>> an answer next days.
>>
>> BTW as more things are at stake as python-mode.el, what would you think
>> about an archiv
>> emacs-python, where all the stuff to edit python-code with emacs is
>> collected?
>
> To be honest, my feeling is that the last thing anyone needs is yet
> another python place. The wiki is already a mess of questions and
> answers and mode specific difficulties. Tie that in with emacs 23/22 and
> ipython or not, the numerous ways you can do python completion etc, it
> needs to be simplified not extended.
>
> Thanks for the heads up about pydb btw, nice.
>
>>
>> For me Launchpad seems perfect for such a thing with its email- and
>> bug-report-integration.
>>
>> There we could discuss the probably best emacs-python configuration -
>> which will change,
>> if someone brings up new things.
>
> I think the emacs wiki is best for this stuff purely because its "there"
> and there are numerous utilities to integrate emacs with emacs wiki
> pages. Just keep links to relevant pages.
>
> You might be right : point the wiki to launchpad and remove all the out
> of date stuff. What do others think?
>
>>
>>
>> Andreas
>>
>>
>>
>>>
>>>   
>>>> --
>>>> http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files
>>>> https://code.launchpad.net/s-x-emacs-werkstatt/
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>
>>>   
>>
>>
>>

-- 
A + Thierry Volpiatto
Location: Saint-Cyr-Sur-Mer - France




--- End Message ---
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python setup ?

[Andreas Röhler]

Xavier Maillard wrote:
> Hi,
>
>Richard Riley wrote:
>
>>> The python-mode used is 5.1.0.
>
>I've changed python-mode a little bit.
>Purpose was to make movements a little bit easier,
>more predictible.
>
> Easier, how easier ? What is so difficult with the default
> bindings ? (serious questions).
>   

Hi Xavier,

well, what means "easier"?

Our personal notion about whats best or fittest not
always is acknowledged by others obviously. Tastes
differ. From that I mean its better not just to look
for the one-and-all solution, but to offer flavors of
modes, so people have the choice. Thats already done
with perl-mode and cperl-mode for example. Nonetheless,
the one-and-all idea seems deep-rooted not just in
religion.

With python-mode.el, people may have good reasons, to
use it as it is - and me to leave it as it is.  Thats
fine with bazaar and other DVCs, we can do that. My
branch doesn't hamper the origin and any further branch
will not. Its just freedom to try and see.

Branch orginated from some request, to close forms more
definitely, more specific. Whilst python looks easy and
indeed is, editing it poses some specific difficulties
resulting from special meaning of whitespace.

Python-mode solved this by offering some repeats: if
you are not at the right indentation, just try the next
one - outer or inner.

Thats OK, thats a possible approach. Here the request
came from a user, who must care to save keystrokes.

Thus I wrote commands precisely closing function or
class, resp. last block. Block conceived as the
smollest hierarchical unit - themselves if no hierarchy
exists.

Too I had some other things in mind: reduction of
complexity, generalisation. Something remains to be
done.

Some reporting facilities have been introduced and
shall be still.

Here new functions as `bzr log' displays it:

`py-next-statement' and `py-previous-statement' set cursor at first char
on line instead of beginning of line
 
py-forward-block, py-backward-block

  py-beginning-of-def-or-class
  py-class-at-point
  py-function-at-point
  py-beginning-of-function
  py-beginning-of-class
  py-end-of-function
  py-end-of-class
  py-end-of-def-or-class
  py-line-at-point
  py-block-at-point
  py-beginning-of-block
  py-end-of-block
 
  py-whats-at-point
 
  py-beginning-of-def-or-class (really "or")
 
  py-beginning-of-def-or-class-if-arg



So far

Andreas Röhler

--
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/
https://code.launchpad.net/s-x-emacs-werkstatt/

>BTW have a look at pydb from Rocky Bernstein, if not done already.
>
> What is it useful for ?
>
>   Xavier
>   

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] [Fwd: Re: python setup ?]

[Andreas Röhler]

--- Begin Message ---
Actually, as an aside, what sort of workflows do people have when
using emacs with something like python? Being relatively new to emacs
I've been struggling slightly with finding an optimal workflow.

For example, in other editors/IDEs my workflow would be something
along the lines of:
1. Edit code
2. Run something like pylint or pychecker over the code, run the unit
tests, etc
3. Run the app via the debugger
4. Catch any crashes or problems in the debugger, fix them, and start
again.

In emacs, cycling from editing code to running it under the debugger
seems a touch fiddly, largely because it seems to involve more than
hitting a single key. I've also tried the 'run/reimport buffer into
the interpreter workflow' without much success, in that I usually just
want to rerun my app from scratch rather than reload just the file I'm
working on.

I suspect that I'm so used to the usual IDE workflow that I'm
overlooking something fundamental. Any insights would be much
appreciated.

Thanks!

Simon

--- End Message ---
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python setup ?

[Andreas Röhler]

Richard Riley wrote:
> Barry Warsaw  writes:
>
>   
>> On Apr 30, 2009, at 3:25 AM, Andreas Röhler wrote:
>>
>> 
>>> With python-mode.el, people may have good reasons, to
>>> use it as it is - and me to leave it as it is.  Thats
>>> fine with bazaar and other DVCs, we can do that. My
>>> branch doesn't hamper the origin and any further branch
>>> will not. Its just freedom to try and see.
>>>   
>> This is true, and experimentation a good thing in the short term.  In  
>> the long term though, a proliferation of branches just confuses people  
>> because no one's sure which is the official branch.  Our lives are  
>> more difficult too because of the python-mode.el/python.el split.
>>
>> So I encourage you to experiment and get user feedback.  Old-timers  
>> (and remember, python-mode.el's been in widespread use for 15 years)  
>> will be wedded to their muscle memory, but if you introduce a user- 
>> visible change that people like, they can be made configurable with  
>> defaults providing the old behavior.  Then it will be possible to  
>> merge your changes back into the official branch.  If you modularize  
>> your changes, then the less controversial ones can get merged in sooner.
>>
>> -Barry
>>
>>
>> 
>
>
> IMO any new "obviously useful" features should be enabled by
> default. Old Timers should have no problem reverting to older
> configurations via settings. A point which generates much contention I
> know. As it is, Python set up is/was a minefield. I have a reasonable
> set up here fwiw,
>   

Yes, you have. Used it month ago, thanks BTW.
Beside the question is still, how the user may get everything needed
installed with one action.
Several possibilities exist: we could make a tarball emacs-python.

Too we should let the user decide, what features to use: ipython or not,
pdbtrack or pydb, which
completion, refactoring, which checks and tests etc.

> This includes pysmell completions for hippie expand and company-mode.
>
> http://richardriley.net/projects/emacs/dotprogramming#sec-1.3
>
>
>
>   

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python setup ?

[Andreas Röhler]

Barry Warsaw wrote:
> On May 4, 2009, at 3:59 PM, Andreas Röhler wrote:
>
>>> IMO any new "obviously useful" features should be enabled by
>>> default. Old Timers should have no problem reverting to older
>>> configurations via settings. A point which generates much contention I
>>> know. As it is, Python set up is/was a minefield. I have a reasonable
>>> set up here fwiw,
>>>
>>
>> Yes, you have. Used it month ago, thanks BTW.
>> Beside the question is still, how the user may get everything needed
>> installed with one action.
>> Several possibilities exist: we could make a tarball emacs-python.
>
> If you have permission of the authors of the other packages, I have no
> problem distributing them in our branch, or making a tarball of them
> available from the Launchpad download page.  It's up to them though.

Thanks a lot. I'll care for that.

It will be great, if emacs-python-folks may use this facility for
emacs-python-things
 independently from existing files, thus python-mode
understood in a broader sense, rather python-mode(s).


>   I tend not to use those other packages and just grab python-mode.el
> from its bzr branch.
>
>> Too we should let the user decide, what features to use: ipython or not,
>> pdbtrack or pydb, which
>> completion, refactoring, which checks and tests etc.
>
> Sure.  I would tend to be more conservative in the default settings,
> so as not to surprise people, but that's just me. :)
>

That's wise. With releases, users shouldn't be bothered with all the
developing stuff.
Also we could consider bundles for beginners as well as for
powered-through master-pythons. :)


Andreas

> -Barryu
>

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python setup ?

[Andreas Röhler]

Richard Riley wrote:
> hi Andreas,
>
> but can one list breakpoints in pydb? Cant see how.
>
> r.
>
>   

info breakpoints

http://bashdb.sourceforge.net/pydb/pydb/lib/subsubsection-info.html

Grüße

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python-mode not working in Ubuntu

[Andreas Röhler]

travis+ml-em...@subspacefield.org wrote:
> Hello,
>
> I am an EMACS user and I know scheme, but I don't know EMACS lisp and I've run
> into a problem where I could use some help.
>
> I installed the following packages on Ubuntu intrepid:
>
> bash$ dpkg -l | grep -E 'emacs|python-mode'
> ii  emacs  22.2-0ubuntu2  
>  The GNU Emacs editor (metapackage)
> ii  emacs22-bin-common 22.2-0ubuntu2  
>  The GNU Emacs editor's shared, architecture
> ii  emacs22-common 22.2-0ubuntu2  
>  The GNU Emacs editor's common infrastructure
> ii  emacs22-gtk22.2-0ubuntu2  
>  The GNU Emacs editor (with GTK+ 2.x support)
> ii  emacsen-common 1.4.17 
>  Common facilities for all emacsen
> ii  python-mode1:1.0-3.1ubuntu4   
>  Emacs-lisp python-mode and doctest-mode for
>
> When I go to edit a python file with emacs, I get this in my messages buffer:
>
> ("emacs" "/tmp/foo.py")
> Loading 00debian-vars...
> No /etc/mailname. Reverting to default...
> Loading 00debian-vars...done
> Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
> Loading debian-ispell...
> Loading /var/cache/dictionaries-common/emacsen-ispell-default.el 
> (source)...done
> Loading debian-ispell...done
> Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
> Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
> Loading /etc/emacs/site-start.d/50psvn.el (source)...done
> Loading /etc/emacs/site-start.d/50pymacs.el (source)...done
> Loading /etc/emacs/site-start.d/50python-mode.el (source)...done
> For information about GNU Emacs and the GNU system, type C-h C-a.
> (New file)
> File mode specification error: (file-error "Cannot open load file" 
> "python-mode")
>
> When I run M-x python-mode, I get this message:
>
> call-interactively: Cannot open load file: python-mode
>
> And yet, it appears to be there:
>
> bash$ locate python-mode
> /etc/emacs/site-start.d/50python-mode.el
> /usr/lib/emacsen-common/packages/install/python-mode
> /usr/lib/emacsen-common/packages/remove/python-mode
> /usr/share/doc/python-mode
> /usr/share/doc/pymacs/contrib/Giorgi/python-mode.diffs.gz
> /usr/share/doc/python-mode/README.Debian
> /usr/share/doc/python-mode/changelog.Debian.gz
> /usr/share/doc/python-mode/copyright
> /usr/share/emacs/site-lisp/python-mode
> /usr/share/emacs/site-lisp/python-mode/doctest-mode.el
> /usr/share/emacs/site-lisp/python-mode/pycomplete.el
> /usr/share/emacs/site-lisp/python-mode/python-mode.el
> /var/lib/dpkg/info/python-mode.conffiles
> /var/lib/dpkg/info/python-mode.list
> /var/lib/dpkg/info/python-mode.md5sums
> /var/lib/dpkg/info/python-mode.postinst
> /var/lib/dpkg/info/python-mode.prerm
>
> Can anyone please help me figure out how to troubleshoot this?
>
> BTW: Thanks for creating such a wonderful editor!  It has really helped me
> as a programmer over the years.
>   


Hi,

case it shouldn't work using the hints given,

(load "/usr/share/emacs/site-lisp/python-mode/python-mode.el")

into your emacs-init-file, probably ~/.emacs, should
do it for the moment in any case.

BTW python-mode.el is maintained at

https://code.launchpad.net/python-mode

I'll cc this mail to python-mode@python.org

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] hide-show support enabled with python-mode.el

[Andreas Röhler]

Thanks for contribution!

Andreas
--- Begin Message ---
  User: aroehler
  Date: 09/09/29 12:18:50

  Modified:packages/xemacs-packages/python-modes python-mode.el
Log:
Add support for HideShow

Mikhail Novikov  delivered this patch at
https://code.launchpad.net/~freiksenet/python-mode/hide-show-support
It enables hs-minor-mode within python-mode.

Revision  ChangesPath
4.56  +21 -0 XEmacs/packages/xemacs-packages/python-modes/python-mode.el

Index: python-mode.el
===
RCS file: 
/pack/xemacscvs/XEmacs/packages/xemacs-packages/python-modes/python-mode.el,v
retrieving revision 4.55
retrieving revision 4.56
diff -u -p -r4.55 -r4.56
--- python-mode.el  2009/09/28 10:44:10 4.55
+++ python-mode.el  2009/09/29 10:18:49 4.56
@@ -366,6 +366,18 @@ to select the appropriate python interpr
   :type 'boolean
   :group 'python)
 
+(defcustom py-hide-show-keywords '("class" "def" "elif" "else" "except"
+ "for" "if" "while" "finally" "try" "with")
+  "*Keywords used by hide-show"
+:type '(repeat string)
+:group 'python)
+
+(defcustom py-hide-show-hide-docstrings t
+  "*If doc strings shall be hidden"
+:type 'boolean
+:group 'python)
+
+
 
 ;; 
 ;; NO USER DEFINABLE VARIABLES BEYOND THIS POINT
@@ -1216,6 +1228,15 @@ py-beep-if-tab-change\t\tring the bell i
 (if (fboundp 'imenu-add-to-menubar)
 (imenu-add-to-menubar (format "%s-%s" "IM" mode-name)))
 )
+
+  ;; Add support for HideShow
+  (add-to-list 'hs-special-modes-alist (list
+   'python-mode (concat (if py-hide-show-hide-docstrings 
"^\\s-*\"\"\"\\|" "") (mapconcat 'identity (mapcar #'(lambda (x) (concat 
"^\\s-*" x "\\>")) py-hide-show-keywords ) "\\|")) nil "#"
+   (lambda (arg)
+ (py-goto-beyond-block)
+ (skip-chars-backward " \t\n"))
+   nil))
+  
   ;; Run the mode hook.  Note that py-mode-hook is deprecated.
   (if python-mode-hook
   (run-hooks 'python-mode-hook)



___
XEmacs-CVS mailing list
xemacs-...@calypso.tux.org
http://calypso.tux.org/mailman/listinfo/xemacs-cvs

--- End Message ---
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Emacs block indentation

[Andreas Röhler]

Jaideep Das wrote:
> I am using emacs 2.2 at work and 2.3 at home for python coding. I want to
> know how can I indent or outdent a block of code multiple times. What I mean
> is when I select a code part using C-space and then use C-x  / C-c-> /
> C-c-< to indent or outdent, this only works once and then deselect the
> block. What if i want to indent multiple times on the same code block do I
> have to repeated this key sequence from selecting the block to indent.
>   

Commit message of latest revision of python-mode.el (note: not
python.el) says:

"When shifting regions right and left, keep the region active in Emacs."

This might solve your problem.

Get it at

https://code.launchpad.net/~python-mode-devs/python-mode/python-mode

or with
 
bzr branch lp:python-mode

HTH

Andreas

--
https://code.launchpad.net/s-x-emacs-werkstatt/






___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] More interactive python

[Andreas Röhler]

Andrea Crotti wrote:
> For some reasons I've never been able to write to python-mode (via
> gmane+gnus) so I'll write it here...
> 

Hi Andrea,

you should not encounter difficulties posting to this list:
Python-mode@python.org

You can also join the mailing list at 
.

I'll forward this message meanwhile.


> It would be nice to have something like
> - execute current function (asking for argument if needed)
> - generate doc string (doesn't make sense to write it manually)
> 
> and so on.
> 
> I've found something but I had some problems and it was using pymacs.
> 
> Pymacs is really nice but apparently in a dead state, so maybe it's
> better to not count too much on it...

Think some people are interested in, me too.

Might be helpful, if you make some bug reports.

tracker is here:

https://bugs.launchpad.net/python-mode

It's the right place for feature requests too.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/


> 
> Is there something already, or maybe do you have any hints on where to
> start to do it??
> Thanks
> 
> 
> 
> 

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] More interactive python

[Andreas Röhler]

Andrea Crotti wrote:
> Andreas Röhler  writes:
> 
>> Andrea Crotti wrote:
>>
>> I'll forward this message meanwhile.
> 
> Well I have no idea, I'm already subscribed
> --8<---cut here---start->8---
> An attempt was made to subscribe your address to the mailing list
> python-m...@python.org.  You are already subscribed to this mailing list.
> --8<---cut here---end--->8---
> 
> But every time I try to send something I only get an error saying I'm
> not authorized, I already tried enough times for my patience unfortunately...


Looks like your adress when sending is another as the one subscribed for. 
Checking your mailers send-adress, when composing a mail should solve it.

> 
>> Think some people are interested in, me too.
>>
>> Might be helpful, if you make some bug reports.
>>
>> tracker is here:
>>
>> https://bugs.launchpad.net/python-mode
>>
>> It's the right place for feature requests too.
>>
> 
> Thanks a lot,
> Bug submitted:
> https://bugs.launchpad.net/python-mode/+bug/517311
> 
> 
> 
> 


See it, thanks.

BTW, do you use IPython  -- An enhanced Interactive Python?

Thats one of the most useful tools IMHO resp. Python and Emacs.

Cheers
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python mode shell and unicode

[Andreas Röhler]

Max Arnold wrote:
> On Sat, Mar 27, 2010 at 06:48:00PM +0100, Andreas Röhler wrote:
>>> My python-shell invoked via C-c C-c from python buffer can not print 
>>> unicode characters (emits
>>> UnicodeEncodeError) and sys.stdout.encoding is empty. System wide LANG set 
>>> to "ru_RU.UTF-8" and
>>> os.environ.get('LANG') in python shell confirms this.
>>>
>>> When python-shell invoked manually (M-x python-shell) there is no encoding 
>>> issues. Any ideas?
>>>
>> What you get from
>> C-h v buffer-file-coding-system?
> 
> ---
> buffer-file-coding-system is a variable defined in `C source code'.
> Its value is utf-8-unix
> Local in buffer test1.py; global value is utf-8-unix
> ...
> It does not apply to sending output to subprocesses, however.
> ---
> 
> Python module contains encoding specification # -*- coding: utf-8 -*- at the 
> beginning.
> Emacs version is 23.1.
> 
> 
> 

Hmm, see inside `python-send-region'

  ;; Fixme: Write a `coding' header to the temp file if the region is
  ;; non-ASCII.

Maybe that indicates the cause?

You could try `py-execute-file' from python-mode.el

CC to mailing list there.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python mode shell and unicode

[Andreas Röhler]

Max Arnold wrote:
> On Sun, Mar 28, 2010 at 09:25:02AM +0200, Andreas Röhler wrote:
>> Hmm, see inside `python-send-region'
>>
>>   ;; Fixme: Write a `coding' header to the temp file if the region is
>>   ;; non-ASCII.
>>
>> Maybe that indicates the cause?
> 
> I think this is unrelated to the issue because my python code contains no
> unicode characters; they are received from parsed web page and then printed
> to stdout. The problem is with python process spawned by Emacs - its stdout
> encoding is not specified (sys.stdout.encoding is None).
> 
> Maybe this is a python feature: 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415968
> 
> But then I do not understand why manually invoked pyton-shell handles unicode
> characters just fine...

Looks like your problem is rather on the python than the emacs side.

If I change the function in the bugreport given above into

def output(s):
# print s.decode('utf-8')
print s

redirecting into FILE with > works


> 
>> You could try `py-execute-file' from python-mode.el
> 
> Sorry, didn't mentioned that I use python.el shipped with emacs. How to 
> disable
> built-in one and enable python-mode.el? 

Download it here

http://launchpad.net/python-mode/trunk/5.1.0/+download/python-mode.el

and get it loaded

 How to invoke py-execute-file from
> M-x prompt?

Just

M-x py-execute-file

should do it

Andreas

> 
> BTW, print u'\xA9' is a nice test for this issue.
> 
> Cheers, Max
> 
> 
> 

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python mode shell and unicode

[Andreas Röhler]

Max Arnold wrote:
> On Sun, Mar 28, 2010 at 04:56:49PM +0200, Andreas Röhler wrote:
>> Looks like your problem is rather on the python than the emacs side.
> 
>> Download it here
>> http://launchpad.net/python-mode/trunk/5.1.0/+download/python-mode.el
>>
>> M-x py-execute-file
> 
> Ok, I placed (require 'python-mode) to init.el and it seems to be activated
> (autoloading didn't worked for me). But M-x shows no available completions
> for py-execute-file:
> 
> Possible completions are:
> py-electric-backspace  py-electric-colon
> py-electric-delete py-end-of-def-or-class
> py-execute-buffer  py-execute-def-or-class
> py-execute-import-or-reloadpy-execute-region
> py-execute-string
> 
> Although C-h f py-execute-file shows it and says it is defined in 
> python-mode.el.
> 
> 
> Next, quick test with print u'\xA9':
> 
> 1. Invoke python shell manually:
> 
> M-x py-shell
>>>> print u'\xA9'
> ©
> 
> 
> 2. Create new buffer containing the same print command, switch it to 
> python-mode
> and use py-execute-buffer:
> 
>>>> ## working on region in file /usr/tmp/python-9773IlV.py...
> ©
> 

So that's what it should do(?)

> 
> 3. Close python shell (opened at step 1) and invoke py-execute-buffer again:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa9' in position 
> 0: ordinal not in range(128)
> 
> 
> Is this really a python problem?  I think there is a difference in how Emacs 
> spawns python
> process in each case.
> 
> 
> 

Hmm, yes, get the same error.
However, if I re-start ipython-shell parallel

it works again

In [11]: ## working on region in file /usr/tmp/python-3766xFD.py...
©


Maybe just start a python-shell to have a work-around?

Sorry, I'm not able to dive into now.

It may help, if you make a bug-report, having it noticed at least here:

https://bugs.launchpad.net/python-mode

Thanks

Andreas




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python mode shell and unicode

[Andreas Röhler]

Max Arnold wrote:
> On Sun, Mar 28, 2010 at 06:34:06PM +0200, Andreas Röhler wrote:
>>> On Sun, Mar 28, 2010 at 04:56:49PM +0200, Andreas Röhler wrote:
>>>> Looks like your problem is rather on the python than the emacs side.
>>>> Download it here
>>>> http://launchpad.net/python-mode/trunk/5.1.0/+download/python-mode.el
>>>>
>>>> M-x py-execute-file
>>> Ok, I placed (require 'python-mode) to init.el and it seems to be activated
>>> (autoloading didn't worked for me). But M-x shows no available completions
>>> for py-execute-file:
>>>
>>> Possible completions are:
>>> py-electric-backspace  py-electric-colon
>>> py-electric-delete py-end-of-def-or-class
>>> py-execute-buffer  py-execute-def-or-class
>>> py-execute-import-or-reloadpy-execute-region
>>> py-execute-string
>>>
>>> Although C-h f py-execute-file shows it and says it is defined in 
>>> python-mode.el.
>>>
>>>
>>> Next, quick test with print u'\xA9':
>>>
>>> 1. Invoke python shell manually:
>>>
>>> M-x py-shell
>>>>>> print u'\xA9'
>>> ©
>>>
>>>
>>> 2. Create new buffer containing the same print command, switch it to 
>>> python-mode
>>> and use py-execute-buffer:
>>>
>>>>>> ## working on region in file /usr/tmp/python-9773IlV.py...
>>> ©
>>>
>> So that's what it should do(?)
> 
> 
> Yes, (1) and (2) is expected behaviour, 0xA9 is the UTF-8 code for copyright 
> symbol (C).
> 
>>> 3. Close python shell (opened at step 1) and invoke py-execute-buffer again:
>>>
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa9' in 
>>> position 0: ordinal not in range(128)
>>>
>>>
>>> Is this really a python problem?  I think there is a difference in how 
>>> Emacs spawns python
>>> process in each case.
>>>
>>>
>> Hmm, yes, get the same error.
>> However, if I re-start ipython-shell parallel
>>
>> it works again
>>
>> In [11]: ## working on region in file /usr/tmp/python-3766xFD.py...
>> ©
>>
>>
>> Maybe just start a python-shell to have a work-around?
> 
> Initially I discovered this problem using python.el. It spawns new python
> process upon C-c C-c even if there is existing one (looks like it launches
> one process per buffer). So this workaround applicable only for python-mode.el
> 
> 
>> Sorry, I'm not able to dive into now.
>>
>> It may help, if you make a bug-report, having it noticed at least here:
>>
>> https://bugs.launchpad.net/python-mode
> 
> Ok, I'll do this.  Should I do the same for python.el somewhere?
> 
> 
> 

Yes, thanks

M-x report-emacs-bug

will provide the destination.

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] [Fwd: Python auto-completion without pymacs]

[Andreas Röhler]

--- Begin Message ---

Given that I had some bad experiences with pymacs I would like to avoid
it entirely, but I would still love to have things like auto completion
or inline documentation.

Anyone has seen some of those features implemented without using pymacs
maybe?
Thanks




--- End Message ---
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] new branch `python-mode-com

[Andreas Röhler]

Hi Barry, hi all,

new branch `python-mode-components' intends
towards a python-IDE as discussed ago.

`python-mode-components' enables use of `imenu' in
python-buffers.

Basiscally it splits up python-mode.el.

That should make further editing easier, permitting
pydb.el alongside with existing pdb-functions etc.

Too the pure number of functions will increase
considerable, if realised.

Just starting. Maybe all should integrate into CEDET still?
See also `thingatpt-python-expressions.el'

at

https://code.launchpad.net/s-x-emacs-werkstatt/

-- which is fairly experimental.

Two minor functions have been added, see below.
Comments welcome.


Andreas

;


(defun py-statement-forward (count)
  "Like `py-next-statement', but moves to the statements text 
beginning, returns position. "

  (interactive "p")
  (py-next-statement count)
  (back-to-indentation)
  (when (interactive-p) (message "%s" (point)))
  (point))

(defun py-statement-backward (count)
  "Like `py-previous-statement', but move to the statements text  
beginning, returns position. "

  (interactive "p")
  (py-previous-statement count)
  (back-to-indentation)
  (when (interactive-p) (message "%s" (point)))
  (point))

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-goto-initial-line doku

[Andreas Röhler]

Hi Barry, hi all,

suggest to drop the second sentence in doku of
`py-goto-initial-line'  --see below-- as it's confusing.

"Usually this is the line we're on" might be true, but
has no syntactic relevance.

It's not obvious, what "a continuation block" should mean.

For me a block is the body of a conditional.

Agreed? Any other opinions?

Cheers

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/



(defun py-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."
...

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] py-goto-initial-line doku

[Andreas Röhler]

Am 21.09.2010 20:27, schrieb Barry Warsaw:

On Sep 21, 2010, at 10:33 AM, Andreas Röhler wrote:

   

suggest to drop the second sentence in doku of
`py-goto-initial-line'  --see below-- as it's confusing.

"Usually this is the line we're on" might be true, but
has no syntactic relevance.

It's not obvious, what "a continuation block" should mean.

For me a block is the body of a conditional.
 

Well, almost the entire docstring makes no sense.

The Python language reference describes these things as "compound statements":

 http://docs.python.org/reference/compound_stmts.html

It goes on to describe the layout of compound statements:

 "Compound statements consist of one or more ‘clauses.’ A clause consists
 of a header and a ‘suite.’ The clause headers of a particular compound
 statement are all at the same indentation level. Each clause header begins
 with a uniquely identifying keyword and ends with a colon. A suite is a
 group of statements controlled by a clause. A suite can be one or more
 semicolon-separated simple statements on the same line as the header,
 following the header’s colon, or it can be one or more indented statements
 on subsequent lines. [...]"

So, how's this for a suggested new docstring:

   "Go to the initial line of the current statement.
When point is on a simple statement, this will go to the start of that line.
When point is on a line inside a compound statement, this will go to the line
that introduces the suite, i.e. the clause header."

If you wanted, you could also add a reference to the online docs for compound
statements given above.

-Barry

   



Thanks,

if the lp:~a-roehler/python-mode/tqs-302834-amend 
<https://code.launchpad.net/%7Ea-roehler/python-mode/tqs-302834-amend> 
branch is merged (?)


the patch from
lp:~a-roehler/python-mode/py-goto-initial-line 
<https://code.launchpad.net/%7Ea-roehler/python-mode/py-goto-initial-line>

should work for you.

So I'll take care of the doku with this new head, send another patch then.

Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] py-goto-initial-line doku

[Andreas Röhler]

Am 21.09.2010 20:27, schrieb Barry Warsaw:

On Sep 21, 2010, at 10:33 AM, Andreas Röhler wrote:

   

suggest to drop the second sentence in doku of
`py-goto-initial-line'  --see below-- as it's confusing.

"Usually this is the line we're on" might be true, but
has no syntactic relevance.

It's not obvious, what "a continuation block" should mean.

For me a block is the body of a conditional.
 

Well, almost the entire docstring makes no sense.

The Python language reference describes these things as "compound statements":

 http://docs.python.org/reference/compound_stmts.html

It goes on to describe the layout of compound statements:

 "Compound statements consist of one or more ‘clauses.’ A clause consists
 of a header and a ‘suite.’ The clause headers of a particular compound
 statement are all at the same indentation level. Each clause header begins
 with a uniquely identifying keyword and ends with a colon. A suite is a
 group of statements controlled by a clause. A suite can be one or more
 semicolon-separated simple statements on the same line as the header,
 following the header’s colon, or it can be one or more indented statements
 on subsequent lines. [...]"

   


Proceeding...
Will put it into the tqs-amend patch, as you are playing with it.


So, how's this for a suggested new docstring:

   "Go to the initial line of the current statement.
When point is on a simple statement, this will go to the start of that line.
   


Think we can't say that.

for example consider the following, which is a simple statement too (?)

print """Usage: %s
""" % (
os.path.basename(sys.argv[0]))


So maybe `print' is considered such a uniquely identifying keyword,
--assuming not--

what about this:

ar_atpt_delimited_list_roh = ([
'braced ?\{ ?\}',
'bracketed ?\[ ?\]',
'angled-lesser ?\<  ?\>',
'angled-greater ?\>  ?\<',
'left-right-singlequoted ?\‘ ?\’',
'parentized ?\( ?\)',
])


Cheers

Andreas




When point is on a line inside a compound statement, this will go to the line
that introduces the suite, i.e. the clause header."

If you wanted, you could also add a reference to the online docs for compound
statements given above.

-Barry

   



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
   


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-backslash-continuation-line-p

[Andreas Röhler]

Hi Barry, hi all,

replaced in

lp:~a-roehler/python-mode/tqs-302834-amend

branch, which is expected for a merge next:

`py-backslash-continuation-line-p'

with

`py-backslash-continuation-preceding-line-p'

as it addresses preceding line, not current.

Adressing the current one might be of some use too, so
preserved the name for it.

BTW doku adresses the comment issue, which isn't at
stake here IMHO

"Return t if preceding line ends with backslash that is not in a comment."

Better just

"Return t if preceding line ends with backslash. "

(?)

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] python-mode-reassembled.el

[Andreas Röhler]

Hi Barry, hi folks,

after some re-design done in

https://code.launchpad.net/~a-roehler/python-mode/python-mode-components,

re-arranged the changed code alongside with the
unchanged into a single file again for your
convenience:

~a-roehler/python-mode/python-mode-components : /python-mode-reassembled.el

Most bugs reported last year should be gone.

Maybe have a look at functions below ";; Block"

which implement some new behaviour or are newly introduced.

Also `ar-py-indent-line-forward' might be of some interest.

Hopefully I'll write some explanations next weeks.

Comments welcome

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Bug 652005] Re: py-beginning-of-block feature request

[Andreas Röhler]

Am 06.10.2010 13:40, schrieb Barry Warsaw:

Hi Andreas, I think it's fine if you discuss this on python-mode@

   

Changes in
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components


Hi Barry, hi folks

as rewrite of python-mode.el is conceived part of a larger
project started at

https://code.launchpad.net/s-x-emacs-werkstatt/

didn't change a single function but a bunch of them
acccording to the rules applied. These rules might be
and should be discussed, didn't find the right place
for discussion so far.

Lanchpads Blueprint seems rather fine-grained, not
suitable for general reflections.

Nonetheless I'd happy seeing python-mode Blueprint
activated, as its fine for simple feature requests.

Just the reason for changing

`py-beginning-of-block'

as an example.

Rules applied :- have regular behaviour, meet and establish
expectations as much as possible.

Regular behaviour :- have regular return values
Regular behaviour :- used options as respective functions use

Return values :- if function moves point - return point

Used options  :- if function moves point - have a repeat count or no option

The `nomark' option has been uncommon, probably
singular in Emacs. No need for that.

Using standard operations as moving point no need to
read the doku should exist.

Dropped the repeat count too for `py-beginning-of-block',

as `py-beginning-of-block-or-clause' like
`py-beginning-of-def-or-class' also has that
except/irregularity as def/class switch.

A well founded except/irregularity so far, kept and
proliferated that.

Cheers


Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] obsolete bugs, Blueprints

[Andreas Röhler]

Hi Skip, hi folks,

seeing Barry gave administration rights to us, we may
now adress the ancient bugs one by one, close the
obsolete. Closing the obsolete should speed up
further development, as the number of good ancient
reports is considerable and probably no one will dig through
there easily.

As I'm still capable of all kind of errors: should some nasty things
happen, please don't hesitate to tell me.

Suggest to activate the button `Blueprints', which
provides a tracker for feature requests AFAIU.

Maybe category `Answers' should be enabled too (?)

Remember interesting discussion on this list some
months ago: would welcome if people dig out
proposals from the archiv

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

and make a fresh entry at `Blueprints'. Thus it remains at the table.

AFAIU `Blueprints' allows further discussing and also
ranging issues with respect for it's importance.

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] go-to-initial-line

[Andreas Röhler]

Hi Barry, hi Skip, hi python-mode folks,

just checked in a fix for `go-to-initial-line'.

It's pretty sure from my perspective, there will be lot
more bugs of these kind be inside the venerable trunk.

Could build a kind machine from abtract reasoning
producing it's reports. However, fixing them on the
base given is rather difficult. For the very reason
this fix is a rather wooden part of plastic.

Bien sure, developers already have remarked that
difficulty and commented it `tricky' inside the code.

IMHO it's difficulty relies in the fact, that every
time cursor changes a state a couple of questions have
be to asked again. It's a matter of design so far, therefor the re-design
in python-mode-components.

The natural solution for me was writing a recursive
function employing `cond', so everytime a condition has
been met, the whole circle starts from the
beginning. That should avoid a whole bunch of bugs.

Would appreciate it much, if you could try the

python-mode-reassembled.el

from inside

https://code.launchpad.net/~a-roehler/python-mode/python-mode-components

`python-mode-reassembled.el' keeps the python-mode ranges
of functions basically, but should avoid the bugs
mentioned.

Thanks all, happy testing,

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Bug in python-mode.el 5.1.0?

[Andreas Röhler]

Am 30.10.2010 12:57, schrieb Christoph Conrad:

Hi,

i assume the following code should be changed:

   ;; TBD: a horrible hack, but why create new Custom variables?
   ;; -cco- OLD: (let ((cmd (concat py-which-shell (if (string-equal 
py-which-bufname
   (let ((cmd (concat shell (if (string-equal py-which-bufname
   "Jython")
 " -" ""

Regards,
Christoph
___


Hi Christoph,

it will be helpful, if you could make an entry in the bugtracker at

https://bugs.launchpad.net/python-mode

Thanks for your reports.

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Time for a new release?

[Andreas Röhler]

Am 05.01.2011 19:45, schrieb Barry Warsaw:

Thanks Andreas and Georg for your recent commits to python-mode.el.  I wonder
if it isn't time to start thinking about an official release, probably of 5.2?
Is there anything else anybody would like to get in, say over the next couple
of days?  If not, I'd be happy to do a release on Friday, but wouldn't mind if
someone else wanted to do it instead.

-Barry



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


Hi Barry,

I'm glad seeing python-mode proceeding.

As for a release, AFAIU we don't have reached Milestone 5.1.1 yet.

Bug #473525 isn't dealt with.
Wanted to look at next days.

Too for my taste there are much more bugs we could adress an current 
code base still.


I'm pretty sure more triple-quote-string bugs exists.
Hopefully I'll be at it next month.

Cheers

Andreas






___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] milestone 5.1.1

[Andreas Röhler]

Hi Barry,

looks like milestone is reached now.
As Skip asked for a tarball...

Cheers

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] milestone 5.1.1

[Andreas Röhler]

Am 08.01.2011 22:57, schrieb Barry Warsaw:

On Jan 08, 2011, at 10:43 PM, Georg Brandl wrote:


I'm not sure whether to keep the string-escaping highlighting; I've started
seeing mishighlighted files again...  did anyone else notice something?


I haven't yet, but I also haven't done a lot of Python hacking with the latest
rev.  I will over the next few days, so perhaps we should let r377 bake for a
few days and either fix the problem, or do a release early next week.

-Barry




Wondered why the graph of milestone doesn't show its fullfilled.
Seems, it requires a "released" declaration.

Both tasks, where the milestone is declared for, are signaled 
"committed". So we get the tarball BTW



Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] avoiding edit wars

[Andreas Röhler]

Hi Barry,

with respect to bug-fixing discussions last days it
might be useful to reflect some rules in order to avoid
edit wars.

If several developers join interest in a solution, it's
fine. However, different persons tend to harbour
different opinions, that's normal.

So how to make decisions then?

Probably you won't have the time to make all. Also voting
might not be realistic for the same reason.

So delegation is needed. How to delegate?

Understood the instrument of assigning a bug to someone
in such, having a person in charge not just for writing
fixes but taking care for the process until it's
committed.

Setting the status flags should be part of the job,
as it signals proceeding, might call others for action
etc.

If people don't agree with decisions of the assignee,
they should post to him/her, but not toggle the flags
themselves.

Finally it's your job IMHO to revoke an assignment, if
disputes can't be settled otherwise.

These understanding seems not common so far.

Happy to see things developing fast last days, what's
great. Just makes it worthwhile to address upcoming
dangers.

Thanks all

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] simplified procedure

[Andreas Röhler]

Hi Barry,

thanks for the merges.

With respect to the still considerable amount of
reports and a possible speed up of it's treatment, please
permit some reflexions, how ease the process:

- as for pure typos, whitespace, indent-matters IMHO
  developers should be permitted to push into the trunk
  without prior notice.

- if funktion is changed, newly introduced, we could
  agree a simplified procedure, saying a delay of three
  days, so people may object.

- in cases of fundamental change I won't act without
  your prior consent.

So far

Andreas

PS

https://code.launchpad.net/~a-roehler/python-mode/string-to-syntax

is still unmerged. It concerns XEmacs only (featurep
'xemacs)...,

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] c/c++ project management and debugging

[Andreas Röhler]

Am 10.01.2011 17:18, schrieb Richard Riley:

Gary  writes:


Le Wang wrote:


My opinion of Eclipse aside, generally, when someone argues  is
  because Google results count is xxx, you should seriously
question
that side of the argument.


I didn't claim it was slow "because Google results count is xxx", I
claimed that it was slow because that was my experience. Stop trying to
put words in my "mouth".



Eclipse isn't slow when using it. Well, not really any appreciable
amount slower than any other dekstop GUI editor. And its certainly a lot
more powerful than most if you are a programmer dealing with multiple
languages or wanting a common look and feel IDE for all projects. Mixed
mode in debian is kind of ok with nxhtml, but Java is nigh on impossible
(well, hard work - what is the status with JDEE now?), python is a
confusing mess (multiple python modes floating around)


Hi Richard,

can't contradict basically, but let me say: python-mode.el
at https://launchpad.net/python-mode

got some momentum.

What about joining the team?
In case you join, I'll propose a milestone "python auto-completion-mode"
during next weeks.

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/




 : of course the

benefits of Eclipse also introduce some overheads but not ones I feel
are detrimental to any development process.



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Merge] lp:~a-roehler/python-mode/string-to-syntax into lp:python-mode

[Andreas Röhler]

Am 12.01.2011 03:50, schrieb s...@pobox.com:


Sorry this got all garbled, however...

 Andreas>  diff python-mode.el.THIS python-mode.el.BASE
 Andreas>  447c447
 Andreas>  <   (syntax (parse-partial-sexp (point-min) 
(point
 Andreas>  ---
 >>  (syntax (syntax-ppss)))
 Andreas>  463c463
 Andreas>  <  (unless (eq 'string (syntax-ppss-context 
(parse-partial-sexp
 Andreas>  (point-min) (point

The call to syntax-ppss-context probably has to be replaced by something
XEmacs-compatible too.

Apologies if I've not read Andreas's diff correctly.

Skip




Hi Skip,

thanks. See I still have to deal with `syntax-ppss-context' unknown to 
XEmacs - which is not a surprise...


Allthough I'm confident solving this within a reasonable time, please 
permit some considerations concerning XEmacs compatibility though.


Unfortunatly the tqs-syntax matter was not just copy-and-paste as Georg 
assumed :-)


Tweaking that in a different environment required some effort. And still 
we have tqs-bugs, just no valid report for it AFAIS.


As the tqs-handling is crucial for any python-mode,  consider that a 
task of first order.


Python.el seems not to show this bug, copy-and-paste indeed might solve 
it here once and for all. But XEmacs compatibility is broken than. As 
XEmacs has proclaimed it's intend to merge up with GNU code, that may 
pay for a while.


Bluntly said: Beside of the pps issue going to be solved, don't foresee 
keeping a fully compatible python-mode. Trying that, I'm afraid we will 
go out of business alltogether.


A solution might be keeping an XEmacs compatible separate version. Would 
mean another split and python-mode version around... :(


OTOH: we could proceed then much faster with the GNU-branch, having 
again a reliable, maybe most advanced python-mode.


Also, when fixing a bug there, we always may have a look, if its 
possible similar inside existing XE branch.


Having a running XEamcs still, I'd be willing to take part.

Well, just addressing the matter

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] confusion about py-string-to-syntax def

[Andreas Röhler]

Am 13.01.2011 21:05, schrieb s...@pobox.com:

I'm trying to get the latest python-mode.el to compile cleanly.  I have this
definition:

 ;; Skip's XE workaround
 (if (fboundp 'string-to-syntax)
 (defalias 'py-string-to-syntax string-to-syntax)
   (defun py-string-to-syntax (s)
 (cond
  ((equal s "|") '(15))
  ((equal s "_") '(3))
  (t (error "Unhandled string: %s" s
   )



Thanks,

though my taste is still the other way around:

as soon as XEmacs merges up to GNU code, would should drop our stuff, 
considered a possible a bug-source than.


With the use of a aliased function I'm afraid, we have the complexity 
and bug source just now.


I'll be patient and look, should someone want to write that in.
Just rather not me :-)

Let's go on

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] confusion about py-string-to-syntax def

[Andreas Röhler]

Am 13.01.2011 22:16, schrieb s...@pobox.com:

 >>>  I'm trying to get the latest python-mode.el to compile cleanly.

Neither of you answered this question.  :-)  How do I get those warnings to
go away?

Skip



Hi Skip,

seems you introduced a bug. Why not use the trunk?

BTW all the "py-"-prefix and defalias considerations here are missing 
the point IMHO in such, as if in further futures XEmacs should provide 
this symbol, the compiler will tell..."defined a second time".


Until then, please let us stay as much as possible with the existing 
code, as tqs-syntax-setting is known to work elsewhere.


If extra stuff is introduced in this context, debugging syntax will be 
harder.


What about removing remaining compiler warnings, which are not 
functional AFAIS? For example introducing some defvars to silence the 
compiler in these cases.


Thanks BTW having brought the compiling question to attention here.

Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] confusion about py-string-to-syntax def

[Andreas Röhler]

[ ... ]

What is tqs-syntax-setting?


Meant: Defining the syntax for the triple-quoted-string.


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] bug?

[Andreas Röhler]

Am 15.01.2011 16:49, schrieb Barry Warsaw:

On Jan 14, 2011, at 09:49 PM, Glenn Linderman wrote:


So here is a minimal test case:


"""
"
"""

def foo( bar ):
_ # cursor stays at left margin instead of indenting.


Confirmed with r390 of python-mode.el.  It's definitely that embedded double
quote.  Change it to a single quote and indentation works just fine.

I know Andreas has been working hard in this area for the past week or so, so
I'll let him follow up.  I'm not filing this as a bug, but if you look at

 https://bugs.launchpad.net/python-mode

you'll see several tqs related problems (most are fix committed).

-Barry

P.S. Welcome to the list!



Hi Barry,

gladly announce: just checked in a syntax independend
string parser with branch `paragraph-fill-warts',
addressing a similar bug.

A syntax independend parser delivers much more BTW than
this workaround ... :-)

Beside fixing/re-designing `py-fill-paragraph'
`py-fill-string' based on the new parser, a couple of
new functions are available.

Made an extract from thing-at-point-utils.el, called
`triplequoted.el'

Also delivering files needed by resp. holding the parser.

The full stuff is at

https://code.launchpad.net/s-x-emacs-werkstatt/

RATIONALE of re-design:

When detecting if inside a triple-quoted-string etc.,
the borders of the object are already known in this
course. Which might be given to fill the string...


Available forms for example:


`ar-triplequoted-atpt' - finds triplequoted strings under cursor
`ar-bounds-of-triplequoted-atpt'

...


`ar-triplequoted-dq-atpt' -  triplequoted strings using doublequotes
...


`ar-triplequoted-sq-atpt' - triplequoted strings using singlequotes
...


`ar-quoted-atpt'

...


`ar-doublequoted-atpt'

...


`ar-singlequoted-atpt'

...


Status: experimental,


Remaining/new BUG :(

error message when loading:


"Error in menu-bar-update-hook: (wrong-type-argument stringp nil)"


Comments welcome

Enjoy


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Version?

[Andreas Röhler]

Am 17.01.2011 13:53, schrieb s...@pobox.com:

I have a branch.  According to bzr diff it's identical to lp:python-mode

 python-mode% bzr diff 
http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/python-mode.el
 python-mode.el
 python-mode%


Seems bazaar diff fails here.

bzr branch lp:python-mode

should deliver the trunk

Later do


bzr pull


from inside the dir to update your local from the trunk


Should avoid also the compile error reported in your other mail.

HTH

Andreas




yet the version in my copy of the code is not 5.2.0:

 (defconst py-version "5.0.0+"
   "`python-mode' version number.")

and the copyright/author info doesn't seem up-to-date:

 ;; Copyright (C) 1992,1993,1994  Tim Peters

 ;; Author: 2003-2008 https://launchpad.net/python-mode
 ;; 1995-2002 Barry A. Warsaw
 ;; 1992-1994 Tim Peters
 ;; Maintainer: python-mode@python.org
 ;; Created:Feb 1992
 ;; Keywords:   python languages oop

What am I missing?

Skip


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Version?

[Andreas Röhler]

Am 17.01.2011 18:53, schrieb s...@pobox.com:


 Andreas>  Seems bazaar diff fails here.

 Andreas>  bzr branch lp:python-mode

 Andreas>  should deliver the trunk

I'm inside my python-mode sandbox:

 % bzr branch lp:python-mode
 Branched 390 revision(s).
 python-mode% bzr status
 unknown:
   python-mode/
   python-mode.elc

It creates a whole other tree.  I don't want an explosion of sandboxes.



Looks like you branched a repo in a repo

A solution is to start from some empty place again.

bzr branch lp:python-mode

creates a dir python-mode



Can't I switch between different branches somehow?


Sure.

Depends what you want to do.




This is perhaps a small point for this, because I can actually get away with
deleting my stuff completely and switching to lp:python-mode.  For more
complex projects though, I should be able to switch between branches.  I
want the equivalent of the cvs and svn commands

 cvs up -r some-other-branch
 svn up -r some-other-branch

Is this not possible with bazaar?


with bazaar you may simply copy locally

cp -pur source new

or push a branch at some distant place

bzr push lp:~/python-mode/blah-and-blub






Skip



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Still broken

[Andreas Röhler]

Am 17.01.2011 20:51, schrieb s...@pobox.com:

I moved ~/src/python-mode out of the way, then from ~/src I executed

 bzr co lp:python-mode

I verified that it says I have version 5.2.0:

 (defconst py-version "5.2.0"
   "`python-mode' version number.")

Byte compilation still fails (in a fresh XEmacs session):

 Compiling file /Users/skip/src/python-mode/python-mode.el at Mon Jan 17 
13:50:21 2011
   !! Symbol's function definition is void ((string-to-syntax))

Skip
___



Hi Skip,

solution for XEmacs 21.5 at least was, evaling the file before compiling it.

Please do a "bzr pull" before anyway, as fboundp got replaced by functionp

HTH

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] [Bug 637955] Re: py-previous-statement fails

[Andreas Röhler]

Am 14.10.2010 13:13, schrieb Andreas Roehler:

** Changed in: python-mode
  Assignee: (unassigned) =>  Andreas Roehler (a-roehler)



Hi Barry,

AFAIS it's gone in the trunk now.

Could you check it again, so it may be closed?

Thanks

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] upcoming release

[Andreas Röhler]

Hi Barry,

enabling XEmacs' handling of triple-quoted-strings fixing bugs known for 
now seems an interesting item from my perspective.


paragraph-fill-warts branch should enable this.

https://code.launchpad.net/~a-roehler/python-mode/paragraph-fill-warts

It comes with a lot of utilities though, some required, some just part 
of the tool-box, where singling-out the required here is possible.


I'm hesitating to propose that for general release, as people might be 
scared by the material, which is just partly python-related.


OTOH, what I'm promessing: it pays.

These utilities will fasten up editing, python-mode and all other.

What about to release a thus experimental brunch for XEmacs users first, 
while it will work for all?


Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] upcoming release

[Andreas Röhler]

Am 29.01.2011 01:06, schrieb s...@pobox.com:


 Barry>  I've merged your branch and will play with it over the weekend.
 Barry>  I'm going to leave it to Skip to verify the XEmacs compatibility
 Barry>  issues (Skip please let us know if you need help getting
 Barry>  Andreas's branch).

I was able to check it out and just load-file'd the python-mode.el.  (Should
I have done more?)  When I tried to format the triple-quoted in this file:

 """
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 """

 class Foo(object):
 @staticmethod
 def bar(aList):
 for x in aList:
 for y in x:
 print y


It complained about ar-bounds-of-comment-atpt.  Shouldn't loading
python-mode.el have complained about that?


yes, thanks.
Added the require-forms.

 Trying to load-file the file

where that symbol was defined failed.

I added the paragraph-fill-warts to the start of load-path and restarted
XEmacs.  I then tried to byte-compile python-mode.el.  That failed with the
usual (for me) complaint about string-to-syntax being missing.



There was an old version in this branch.
Checked in the new one. Also the sequence of new forms had to be changed.

Some compile warnings remain with XEmacs 21.5.

Could you pull again and check?

Andreas


I'll wait for these problems to be resolved before doing more.

Skip



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] upcoming release

[Andreas Röhler]

Am 28.01.2011 23:09, schrieb Barry Warsaw:

On Jan 28, 2011, at 10:56 PM, Andreas Röhler wrote:


enabling XEmacs' handling of triple-quoted-strings fixing bugs known for now
seems an interesting item from my perspective.  paragraph-fill-warts branch
should enable this.
https://code.launchpad.net/~a-roehler/python-mode/paragraph-fill-warts It
comes with a lot of utilities though, some required, some just part of the
tool-box, where singling-out the required here is possible.  I'm hesitating
to propose that for general release, as people might be scared by the
material, which is just partly python-related.  OTOH, what I'm promessing: it
pays.  These utilities will fasten up editing, python-mode and all other.
What about to release a thus experimental brunch for XEmacs users first,
while it will work for all?  Andreas


Andreas, as always, thanks for your hard work on python-mode!  It's very much
appreciated.

I've merged your branch and will play with it over the weekend.


Hi Barry,

sounds great.


I'm going to

leave it to Skip to verify the XEmacs compatibility issues (Skip please let us
know if you need help getting Andreas's branch).

python-mode.el has always been self-contained, meaning people can easily
download or copy one file and get great Python support in Emacs.  Requiring
your utilities changes that, and can make it harder for some folks to adopt
python-mode.el.


Indeed, that's my concern too.


 I'm not saying that necessarily means it can't be done, but
we do have to think about the ramifications.  I'd like to get other folks
thoughts on that.

OTOH, I encourage you to get your code into upstream Emacs and XEmacs.  That
would certainly make our lives easy again. :)

Do you think it would be possible and easy to pull out just the parts that
python-mode.el needs and include those in that file?


That can be done.

OTOH it's rather hard keeping that stuff parallel.



If not, then what about
making sure python-mode.el gracefully degrades when those extra files aren't
there?



Don't see that, comment below.


By that I mean, if someone does not have your new utilities, python-mode.el
should at least work as well as it does currently.  python-mode.el should then
take advantage of your utilities if they're available.

Thoughts?
-Barry



As it's XEmacs only, which enforced the re-write, maybe
we should wait if it works there.

In case it works, could extract the needed stuff to
it's required minimum.

Nontheless GNU Emacs won't need it, so keeping the
syntax-parsing as it is for GNU Emacs users will be an
option.

Also in case XEmacs merges up to GNU code, the
regexp-backed parser will not be needed any more.

OTOH there are some gains adressed already in the
second-level-command blueprint.

For me the best would be maintaining for a certain time
basically three branches

- the classic, presently de facto GNU only

- XEmacs special triple quoted string debugged, but
  fine for GNU Emacs also

- a second-level-command enabled IDE. As this slc's
  will count in thousands and ten-thousands, using it
  needs an understandings of it's construction, i.e. of
  the cross-use of it's underlying lists:

  `ar-hide-bracketed-in-line-atpt' for example hides
   everything insides brackets within the given line.
   Resp. `ar-show-bracketed-in-line-atpt' displays it
   again, `ar-hide-show-bracketed-in-line-atpt' toggles
   this state.

   You have `ar-hide-bracketed-in-parentized-atpt' and so on.
   See the comment in `thingatpt-utils-base.el' for more.

As for the latter, think we still need some time to
discuss and check it's usefulness.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] upcoming release

[Andreas Röhler]

Am 29.01.2011 16:03, schrieb s...@pobox.com:


 Andreas>  Could you pull again and check?

I get failures when I visit a .py file.  load-path includes your version at
the front:

 ("/Users/skip/src/paragraph-fill-warts" "/Users/skip/emacs/sql"
 "/Users/skip/emacs/url" "/Users/skip/emacs"
 "/Users/skip/local/lib/xemacs/site-lisp"
 ...
 "/Users/skip/local/lib/xemacs-21.4.22/lisp/")

and (find-library "python-mode") confirms that it finds your version.

When I visit a .py file I get this error though:

 File mode specification error: (file-error "Cannot open load file: %s" 
misc-utils)

Skip



Ok, so let's have it. Pushed just now.

Thanks and sorry...

BTW, as mentioned in another posting, will strip down all that stuff if 
it works for you finally.


Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] upcoming release

[Andreas Röhler]

Am 29.01.2011 17:12, schrieb s...@pobox.com:


 Andreas>  Ok, so let's have it. Pushed just now.

File mode specification error: (file-error "Cannot open load file: %s" 
string-strip)



ehm... pushed



load-path:

 `load-path' is a simple built-in variable.

 Value: ("/Users/skip/src/paragraph-fill-warts"  ...

Skip



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] upcoming release

[Andreas Röhler]

Am 29.01.2011 17:41, schrieb s...@pobox.com:

Latest error:

   File mode specification error: (file-error "Cannot open load file: %s" 
sh-beg-end)


Well, it's able to jump to beginnings- and end of shell blocks, what the 
common GNU mode can't


This world should be finite though...

added and pushed



Skip





___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Latest error

[Andreas Röhler]

Am 29.01.2011 18:16, schrieb s...@pobox.com:


Looks like thingatpt-utils-base requires thingatpt-highlight which doesn't
exist in the checkout.  I evaled all the (require) statements from the .el
files in a (progn) block:

 (progn
 (require 'easymenu)
 (require 'ansi-color)
 (require 'ar-comment-lor)
 (require 'beg-end)
 (require 'cl)
 (require 'comint)
 (require 'compile)
 (require 'custom)
 (require 'info-look)
 (require 'misc-utils)
 (require 'mmm-auto)
 (require 'pymacs)
 (require 'reporter)
 (require 'sh-beg-end)
 (require 'sh-script)
 (require 'string-strip)
 (require 'thingatpt-utils-base)
 (require 'overlay)
 (require 'imenu)
 (require 'thing-at-point-utils)
 (require 'thingatpt-highlight)
 (require 'python-mode)
 )

thingatpt-highlight was the only one it complained about.

Skip


Hmm, seems I underestimated the issue.

added and pushed.

Thanks being that attentive.

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Latest error

[Andreas Röhler]

Am 29.01.2011 18:52, schrieb s...@pobox.com:

 >>  thingatpt-highlight was the only one it complained about.

 Andreas>  Hmm, seems I underestimated the issue.

 Andreas>  added and pushed.

I'm getting farther.  Looks like thingatpt-highlight was missing

 (when (featurep 'xemacs) (require 'overlay))

so I added that to get the make-overlay function.  Then I could visit the
Python file without errors.  Recall the file looks like this (without the
extra indentation):

 """
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 """

 class Foo(object):
 @staticmethod
 def bar(aList):
 for x in aList:
 for y in x:
 print y

When I try to fill the docstring using fill-paragraph-or-region (M-q) with
point ahead of the first 't', it still deletes the space ahead of the first
single quotation mark, leaving me with this:

 """
 triple-quoted string containing"quotation" marks.


which is the charateristic error of failing forward-sexp,

As that form doesn't exist in new version, it means, we got the old 
chunk back


See the error was done with revision 391

Will take some minutes to get it back.



 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 """

If I place point at the beginning of the last line and fill, I get this:

 """
 triple-quoted string containing"quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.  triple-quoted string 
containing"quotation" marks.
 """

Repeat again, and I get:

 """
 triple-quoted string containing"quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.  triple-quoted string 
containing"quotation" marks.  triple-quoted string containing"quotation" marks.
 """

I can proceed to do this until I'm left with a single line in the docstring.

Skip



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] paragraph-fill-warts branch

[Andreas Röhler]

Hi Skip,

the old bug should be gone now.

As its redone from the bottom, filling isn't correct yet.


However, borders of triple-quoted-string now are recognised,

`ar-bounds-of-triplequoted-atpt' should report it for example,

the remaining should not be a rocky mountain.


Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] paragraph-fill-warts branch

[Andreas Röhler]

Am 29.01.2011 22:34, schrieb g.bra...@gmx.net:


 Original-Nachricht 

Datum: Sat, 29 Jan 2011 15:20:56 -0600
Von: s...@pobox.com
An: "Andreas Röhler"
CC: python-mode@python.org
Betreff: Re: [Python-mode] paragraph-fill-warts branch




 Andreas>  the old bug should be gone now.

 Andreas>  As its redone from the bottom, filling isn't correct yet.

 Andreas>  However, borders of triple-quoted-string now are recognised,

 Andreas>  `ar-bounds-of-triplequoted-atpt' should report it for
example,

 Andreas>  the remaining should not be a rocky mountain.

Looks much better.  Goes from this:

 """
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 """

to this:

 """ triple-quoted string containing "quotation" marks.  triple-quoted
string
 containing "quotation" marks.  triple-quoted string containing
"quotation"
 marks.  triple-quoted string containing "quotation" marks.
triple-quoted
 string containing "quotation" marks.  """

no matter where I place the cursor.


Which is not how this should work.

* If there is an initial linebreak it should remain there.
* If there is a final linebreak it should remain there.

And if there is no initial linebreak, please do not put a
space between the quotes and the docstring text.

Georg


Hi Georg, hi Skip,

just checked in a new version of fill-warts branch and also components 
branch


It's definitly upwards the hill, but some issues remain.

We have a bug in GNU's fill.el

After paragraph-fill-function is called, it should retire from all other 
work.


Unfortunatly later on (fill-region-as-paragraph beg end justify) comes 
across and messes it up.


Altogether looks with GNU still better than with XEmacs, which 
progresses also.


To make some pieces from the remaining:

Could you check with `py-fill-paragraph' directly leaving out M-q?
That would make it easier coming to some result.

When reporting the remaining bugs, please make an entry in the tracker 
and mention the kind of Emacs/version.


Thanks all

Andreas





___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] paragraph-fill-warts branch

[Andreas Röhler]

Am 30.01.2011 23:16, schrieb s...@pobox.com:


 Andreas>  When reporting the remaining bugs, please make an entry in the
 Andreas>  tracker and mention the kind of Emacs/version.

Done:

   https://bugs.launchpad.net/python-mode/+bug/710373

Andreas, if you would like a login on my Mac laptop so you can play with my
version of XEmacs, let me know.  I suspect you will converge on working code
more quickly if you don't have to wait for me to complain.

Skip



Thanks, looks like a nice play.

So I must log in via ssh?

May you use my public key vom lp?

Not sure about the steps for this.


Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el

[Andreas Röhler]

Am 03.02.2011 21:23, schrieb Georg Brandl:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- From reading emacs-devel, it seems that the python.el has made
changes to the mode and explicitly taken them out of the copyright
assignment for the FSF, so Emacs upstream can't include them.

So now we are at three different python modes for Emacs... :|

Georg


Hi Georg,

thanks pointing to it.

However, let me clarify: Emacs _can_ include, as long it is GPL and it is.

And so we can.

It's just to give up the insane copyright-policy, where I see no 
legitime reason for, which denigrates the GPL as such.


Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el

[Andreas Röhler]

Am 03.02.2011 22:48, schrieb Aaron Culich:

On Thu, Feb 3, 2011 at 1:13 PM,  wrote:



Georg>  - From reading emacs-devel, it seems that the python.el has made
Georg>  changes to the mode and explicitly taken them out of the
Georg>  copyright assignment for the FSF, so Emacs upstream can't include
Georg>  them.

Georg>  So now we are at three different python modes for Emacs... :|

I'm not sure I understand.  Someone forked python.el but won't allow the
changes to go back into the GNU version?  Wouldn't that violate the GPL or
LGPL.  Who did this?



Copyright assignment is an issue separate from the license itself. To the
extent that Dave's version is derived from the existing python.el then the
GNU GPL still applies to his version of python.el if he distributes it to
other people. He is the "owner" of the new code that he has written, so that
means if he finds someone that redistributes his code in a manner that is
violating the GNU GPL license, then he has the legal standing to pursue that
violation in court as the copyright holder. However, no one else has the
right to pursue it in court on his behalf; you could bring a case to court,
but it would be thrown out in just the same way as if you tried to bring a
lawsuit against someone illegally redistributing MS Word; you can't sue
someone for that, but Microsoft can if they chose to. The license, whether
free or proprietary, can only be enforced in the courts by the copyright
holder.

The issue of enforcement is one of reasons that the GNU project long ago
made a requirement that any code contributions accepted back into the code
base and officially branded as GNU software must also have any accompanying
copyright assignment.

There are other reasons, as well, including protection from patents so that
it would prevent someone from contributing source code to the GNU project on
one hand, and then on the other hand using patents against the same set of
code. You can read that in the language of one of the example copyright
assignment forms I've linked to below.

-Aaron

Here is some further reading:

An official statement about why they require copyright assignment:
http://www.gnu.org/licenses/why-assign.html

An example of the copyright assignment form
http://gcc.gnu.org/ml/gcc/2002-09/msg00678.html

Excerpt from the above form intended to protect against harm from patents:


The Assigner hereby agrees that if it has or acquires hereafter any
patent or interface copyright or other intellectual property interest
dominating the program enhanced by the Work (or use of that program), such
dominating interest will not be used to undermine the effect of this
assignment, i.e. the Foundation and the general public will be licensed to
use, in that program and its derivative works, without royalty or
limitation, the subject matter of the dominating interest.  This license
provision will be binding on the assignees of, or other successors to, the
dominating interest, as well as on the Assigner.



Hi Aaron,

saw you digged into this only after sending my short statement with 
other post.
Sorry for that, would have been more explicit seeing the interest in the 
matter.


It is wast one beside.

FSF thinks by making these assignment provisions,
--partly to the extent of the contributors, setting
them on risk rather than the FSF itself-- to do
something good.

Far from that: by raising the level of
specification already it provides uncertainty rather
than certainty.

Let me point at the risks already introduced by GPL in
this globalised world. Any conflict around would
endanger contributors, as being summoned before a
Bostonian court many of them will not be able to pay
 the costs.

From this perspective GPL already bears a --rather
unspecified-- but potential menace and danger for all
using it.

Decided taking that risk, as you see. But I'm not
willing to take more.

As for copy-rights I'm protected by our domestic laws,
which promess even gratis assistance in certain cases
of conflicts. Why should I give up that protection by
signing up to US-courts?

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el

[Andreas Röhler]

[ ... ]

  He must

have a big bee in his bonnet.




Always being patient with the genial.

Which permits being patient with the common one, including myself.

:-)

Cheers

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el

[Andreas Röhler]

Am 04.02.2011 16:30, schrieb Barry Warsaw:

On Feb 04, 2011, at 09:16 AM, Andreas Röhler wrote:


However, let me clarify: Emacs _can_ include, as long it is GPL and it is.


But they won't.


And so we can.


Yes, we're not bound by the same copyright assignment policy.


It's just to give up the insane copyright-policy, where I see no legitime
reason for, which denigrates the GPL as such.


The FSF has their reasons,


Hi Barry,

I'm consenting to that. There is some rationale.

 which I think are legitimate for them.


As much as I wish we could merge all the different versions and get
python-mode.el into GNU Emacs, it may simply be impossible - or not worth the
effort.


Policies tend to change. BTW assigned the disclaimer of FSF and there 
are some lines by me already in GNU Emacs. So assignment is not an 
absolute barrier even now.


:-)

Andreas

  Apologies for fanning those old flames again.


-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] py-match-paren

[Andreas Röhler]

Hi Barry,

herewith a function I'm used to when editing and didn't want miss it in 
python-mode.


Maybe have a look, if it seems useful for others too.

Needs

(require 'beg-end)
(require 'thing-at-point-utils)
(require 'thingatpt-utils-base)

from https://code.launchpad.net/s-x-emacs-werkstatt/

which are present already in branches:

lp:~a-roehler/python-mode/paragraph-fill-warts
lp:~a-roehler/python-mode/python-mode-components

;

;;   (define-key py-mode-map [(%)] 'py-match-paren)
(defun py-match-paren (arg)
  "Go to the matching brace, bracket or parenthesis if on its counterpart.
Otherwise insert the character, the key is assigned to, here `%'.
With universal arg \C-u insert a `%'. "
  (interactive "P")
  (if arg
  (self-insert-command (if (numberp arg) arg 1))
(cond
 ((looking-at "(")
  (goto-char (ar-parentized-end-position-atpt))
  (backward-char 1))
 ((looking-at ")")
  (goto-char (ar-parentized-beginning-position-atpt)))

 ((looking-at "\\\[")
  (goto-char (ar-bracketed-end-position-atpt))
  (backward-char 1))
 ((looking-at "]")
  (goto-char (ar-bracketed-beginning-position-atpt)))

 ((looking-at "{")
  (goto-char (ar-braced-end-position-atpt))
  (backward-char 1))
 ((looking-at "}")
  (goto-char (ar-braced-beginning-position-atpt)))

 (t (self-insert-command 1))
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Latest paragraph-fill-warts branch

[Andreas Röhler]

Am 13.02.2011 22:50, schrieb s...@pobox.com:

I don't know where we left things w.r.t. the Andreas's paragraph-fill-warts
branch, but I just updated and fired up a new copy of XEmacs.  Then edited
my current small test file.  After filling the doc string I see the same
issue reported before by (I think) Georg.  When filling this:

 """
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 triple-quoted string containing "quotation" marks.
 """

I wind up with this:

 """ triple-quoted string containing "quotation" marks.  triple-quoted 
string
 containing "quotation" marks.  triple-quoted string containing "quotation"
 marks.  triple-quoted string containing "quotation" marks.  triple-quoted
 string containing "quotation" marks.  """

That is, the newline after the first tqs and before the last tqs are not
preserved. This would have been ideal:

 """
 triple-quoted string containing "quotation" marks.  triple-quoted string
 containing "quotation" marks.  triple-quoted string containing "quotation"
 marks.  triple-quoted string containing "quotation" marks.  triple-quoted
 string containing "quotation" marks.
 """

Also, take a look at the attached png file.  Is it possible to color
"quotation" green?

Skip


Hi Skip,

the basic reason is XEmacs' syntax bug.

Going to do regexp-based string parsing instead.

However, detected several bugs in the new parser and just this morning a 
fundamental one, so I'm re-writing major parts.


I'll send a message if ready for testing.

As for your last question resp. string colors, this would need a change 
in fontifying afterwards.


As XEmacs already is slow here, I'm not a XEmacs hacker, I'm afraid this 
will persist - unless someone fixes it.


Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] paragraph-fill-warts

[Andreas Röhler]

Hi Skip,

paragraph-fill-warts bug should be cured now for XEmacs too in
python-mode-components branch.

Will set branch `paragraph-fill-warts' on `obsolet'.

Realised finally the related XEmacs-compat stuff inside
python-mode-components, which turned out much easier.

Might be some differences in the API.

`py-fill-paragraph' should work,
but M-q `fill-paragraph' not - due to a bug in fill.el.

Will see how the new python.el deals with that :)

Exists a test `py-fill-paragraph-problems-710373' in 
py-bug-numbered-tests.el which worked for me with XEmacs 21.5



Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] release?

[Andreas Röhler]

Hi Barry,

from my perspective a release is feasible, after triple
quoted string bugs should be gone.

After release, I'll toggle the bug flags, so it will no
longer list as open.

Also would do a release of python-components-mode afterwards,
which should fix the paragraph-fill bugs too.



Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Announcement of a new python major-mode on emacs-devel

[Andreas Röhler]

Am 16.02.2011 18:51, schrieb Barry Warsaw:

On Feb 16, 2011, at 10:34 AM, m h wrote:


* patch the new code to pull in any missing python-mode.el functionality

The latter could be seen as a merge that would give a one true mode
with superset functionality.  It would also get python-mode
effectively into the emacs distribution (ending the recurring "when
will copyright assignment be given to the FSF threads seen every so
often".


That might be the most fruitful avenue for a merge.  I don't have the cycles
to do that, but perhaps Andreas could reach out to the new python.el author on
our behalf and see about the feasibility of that.

-Barry




Hi Barry,

AFAIS all the python modes own a lot from each other, so there are not 
really different modes but branches.


The new python.el comes with some interesting docu features, we should 
check and maybe pick.


For the moment I'm still at the syntax- resp. XEmacs-compat ie 
non-syntax-parsing issue.


The latter is slower but somehow interesting, as purely emacs-lisp based 
and looks promising for some more tasks beside python-string-detection. 
However, not ready yet...



Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] release?

[Andreas Röhler]

Am 15.02.2011 20:54, schrieb Barry Warsaw:

On Feb 15, 2011, at 08:52 PM, Andreas Röhler wrote:


from my perspective a release is feasible, after triple
quoted string bugs should be gone.


Sorry, I don't quite understand.  Do you mean that we should release r396 or
that you have a few more patches to go in to fix the triple quoted string
bugs?



Hmm, the bugs exists only for XEmacs now AFAIS.

But fixing it there will open more bugs then closing that way probably.
Which doesn't mean it's a bad thing, because it should open some route 
to much more gains. However, it's not a simple bug-fix.


Therefor would close the tqs-reports setting it to "released".
Not sure, if previous release already took the syntax patch.

If yes, could toggle the reports now.

Andreas



Is the NEWS file up to date?

Also, would this be a 5.3.0 or 5.2.1?


After release, I'll toggle the bug flags, so it will no
longer list as open.

Also would do a release of python-components-mode afterwards,
which should fix the paragraph-fill bugs too.


Let me know when you're ready and I push the release button.
-Barry



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] release?

[Andreas Röhler]

Am 17.02.2011 22:44, schrieb Barry Warsaw:

On Feb 17, 2011, at 04:39 PM, Andreas Röhler wrote:


Hmm, the bugs exists only for XEmacs now AFAIS.

But fixing it there will open more bugs then closing that way probably.
Which doesn't mean it's a bad thing, because it should open some route to much 
more gains. However, it's not a simple bug-fix.

Therefor would close the tqs-reports setting it to "released".
Not sure, if previous release already took the syntax patch.

If yes, could toggle the reports now.


Andreas,

I actually realize that you are a member of ~python-mode-devs so you should be
able to do a release on your own.  Why don't you give it a try and let me/us
know if you have any problems.  You could even send the announcement to
python-annou...@python.org.

You're doing most of the work these days, so you should get the credit. :)

-Barry


Thanks a lot, Barry,

as for the tqs I remember you just answered these days it works for you.
I'll close these reports then.

Remain several other indent-bugs - beside stuff not touched yet.

Hopefully next week we can have a bugfix release of the trunk.

Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight bug?

[Andreas Röhler]

Am 25.02.2011 12:18, schrieb andrea crotti:

Before I wasn't sure if it was an old bug, but today I got the last
revision from bzr and I see the same.

Function and variable names containing reserved keywords are not
highlighted correctly.
For example in

def generate_random_tuple()

tuple is colored as it was the tuple function call...
Anyone else seeing this?


Hi Andrea,

thanks for the report.

Could you make an entry in the bug-tracker at launchpad?
That would help.

Did you check out the trunk?
Highlight bugs have been fixed last weeks.

BTW can't reproduce it with my personal components branch.

As I'm still behind indent issues, would look further at a later time.


By the way I've seen many comments about it but I never really
understood, why this python-mode is not included
in emacs instead of the crappy default one?


Hmm, it's a little bit more complicated IMHO.

At python.el was done the the triple-quoted-string syntax fix lately, 
where we profit from. Also python.el merged in a lot from python-mode.el 
last month's. So the code base looks not so different now.


Let's see if we can assist each other to have a nice python environment

Thanks again

Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight bug?

[Andreas Röhler]

Am 25.02.2011 13:32, schrieb andrea crotti:

Ok first I need to be sure I'm up to date.
I'm at revision 396, and also here
https://code.launchpad.net/~python-mode-devs/+ownedbranches
I see the same as last commit done...

Are there any more advanced branches?



usually I start here:

https://code.launchpad.net/python-mode
BTW my components branch is still heavily changed, major changes underway...

Have a look at the thing-at-point utils stuff nonetheless, for me it's a 
rocket~~~:===>



For python-mode/python.el good to know, as long as it's sharing and
helping and not fighting is not a problem...



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight bug?

[Andreas Röhler]

Am 25.02.2011 16:30, schrieb andrea crotti:

2011/2/25 Andreas Röhler:

usually I start here:

https://code.launchpad.net/python-mode
BTW my components branch is still heavily changed, major changes underway...

Have a look at the thing-at-point utils stuff nonetheless, for me it's a
rocket~~~:===>


For python-mode/python.el good to know, as long as it's sharing and
helping and not fighting is not a problem...



Oh God I found the problem, I think probably after the last update of
cedet I have this not so funny behaviour
When emacs starts I get this:
python-mode is an interactive compiled Lisp function in
`python-mode.el'.

After I open the first python file it becomes:
"python-mode is an interactive compiled Lisp function in `python.el'.

(python-mode)"

So I'm just using the wrong thing but I didn't notice because
"locate-library" also gave me the right file.

Any way to solve this "conflict" once for all?



Using some function to toggle several branches/modes like this


 (set-buffer (get-buffer-create "test.py"))
  (erase-buffer)
  (when (featurep 'python-mode)(unload-feature 'python-mode t))
  (fundamental-mode)
  (setq py-python-command-args '("-colors" "Linux"))
  (add-to-list 'load-path NEW-PATH...

then load some python-stuff into, call python-mode again.

HTH

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/





___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight bug?

[Andreas Röhler]

Am 25.02.2011 16:35, schrieb andrea crotti:

Uhm even forcing the load of the file python-mode.el doesn't work.

But I think I found it, in wisent-python.el there is
;; Try to load python support, but fail silently since it is only used
;; for optional functionality
(require 'python nil t)

Which if I get it right hides the python-mode function defined before.
So should I complain on the cedet list or there is still something that
can be done from my side?


Write a blueprint at launchpad and propose cedet-integration. :-)

Seriously, have thought at that, it's welcome.

Don't know what will happen, if you just comment out that line.
Maybe Cedet requires some specific API from python.el?

Then an alias to an function from python-mode may help. And so on.
Differences are not that numerous AFAIS.

Given the blueprint and your interest, your experiences with Cedet might 
be valid for further development anyway.



Strange I never noticed this thing before...



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] highlight-indentation

[Andreas Röhler]

Hi Barry,

just seeing highlight-indentation by Anton Johansson - thanks a lot to 
him BTW -


which I suggest to include into next release.

It delivers graphical bars indicating the indent-level, makes em more 
impressive. Might be useful in certain circumstances.



Source:

https://github.com/antonj/Highlight-Indentation-for-Emacs/blob/master/highlight-indentation.el


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight-indentation

[Andreas Röhler]

Am 11.03.2011 13:47, schrieb Barry Warsaw:

On Mar 09, 2011, at 10:24 PM, Andreas Röhler wrote:


just seeing highlight-indentation by Anton Johansson - thanks a lot to him
BTW - which I suggest to include into next release.

It delivers graphical bars indicating the indent-level, makes em more
impressive. Might be useful in certain circumstances.


Hi Andreas, Anton,



Hi Barry,


Indeed, I agree that this could be very useful in some situations.


good news :-)

 It can be

a little distracting, so it probably should not be turned on by default,



as it's just a function, user may call them or not. It doesn't interfere.

BTW exists still another nice tool of the same author at:

http://stackoverflow.com/questions/1587972/how-to-display-indentation-guides-in-emacs


(defun aj-toggle-fold ()
  "Toggle fold all lines larger than indentation on current line"
  (interactive)
  (let ((col 1))
(save-excursion
  (back-to-indentation)
  (setq col (+ 1 (current-column)))
  (set-selective-display
   (if selective-display nil (or col 1))

(global-set-key [(M C i)] 'aj-toggle-fold)

Maybe have look.


 but

for those cases where the indentation is really hard to follow, I think this
could be a very nice addition.

Is this file going to be added to Emacs?  It seems more general than just for
Python (e.g. turn it on in python-mode.el).

One minor nit: I wonder if it makes sense to highlight columns that are not in
the leading whitespace.  For example, turn it on and look at the define-key
lines starting at about line 845 in python-mode.el.  There are some
highlighted indentation extents after the "\C-c:" string.  Those don't seem
useful.


Yes, seeing that too.

AFAIU it will be hard to cure, as the function sets consecutive 
whitespaces as keywords. Trailing whitespaces are marked that way too.


Also it only occurs if large whitespaces are somewhere between.

For the purpose of quickly indicating multiple indents it's fine.
So don't see a need to ask for a change at this state.


Andreas






Thanks for pointing it out, and thanks to Anton for writing it.

Cheers,
-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight-indentation

[Andreas Röhler]

Am 12.03.2011 04:28, schrieb Barry Warsaw:

Hi Andreas,

I noticed that you committed this file to our bzr tree.



Hi Barry,

took preceding exchange for an approval. Will be more carful next time.


 I'm concerned about

doing this without Anton's approval (and maybe even with it).  Anton probably
has his own source code repository, so at the very least it would be more
effort for us to keep our copy up-to-date with his.  python-mode.el doesn't
depend on his code, so it's really not necessary for us to have a copy in our
tree.

As cool as Anton's module is, and it definitely could help Python programmers,
it's probably a better idea to add a reference to his work (and his download
site or source repository) in our README file or in the comments at the top of
python-mode.el.

If Anton really wants us to keep the canonical version of his mode in our bzr
tree, we could discuss that.  Anton, what do you think?

Cheers,
-Barry



As for the approval: thought that's precisely what the
GPL is for.

So if an author publishs it's code under GPL, that's for
the very reason others may take it, isn't it?

Beside I gave credits with commit message, inside the
header and also dropped a notice to the author.

Which doesn't mean your concerns are invalid, posed
them for me also and answered them as given
above.

Likewise as for the technical aspects of repository:

Having useful Emacs code all around the net, it's just
the situation we are in. It's not all bad with that,
makes some pleasure to look around, trying this and
that.

As for my concern here I'm heading for an IDE, where
people open Emacs and find ererything ready for Python
edits as far as the state of art delivers it.

That means the question you raised concerning
whitespaces for examples must be discussed before and
at place. You can't know what our creative folks will
be have in mind next, if it will be suitable, more or
less, buggy more or less and so on. It's not done with
links delivered.

If we will provide an Python-IDE we must be able to
tell:

here is it's specification, it will work for these
conditions, makings that requirements.

Therefor we must collect the code for the specified
purpose, IMHO :-)

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight-indentation

[Andreas Röhler]

Hi Anton,

thanks a lot BTW.

Added a link onto your repo into the header.

In order to get a wider audience with resp. to other modes an entry
at

http://www.emacswiki.org/emacs-en

might be useful.


As for bug-tracking think we should forward any report to you, if it 
concerns your file(s). OTOH would not charge the users which such 
specific requests.


Agreed?

Thanks again.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/




Am 12.03.2011 11:38, schrieb Anton Johansson:

Hello,

I'm absolutely cool with you guys using the code in any way you find
suitable, nice to see some people finding it useful!

Like you have discussed before, there are some issues with
highlight-indentation.el that could be handled better, for example
highlighting spaces that are not in the leading whitespace. If you can
find a good way to link to my repo so that people can submit possible
fixes that would be good since the code is also usable in other modes.

Cheers
-Anton

On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsaw  wrote:

Hi Andreas,

I noticed that you committed this file to our bzr tree.  I'm concerned about
doing this without Anton's approval (and maybe even with it).  Anton probably
has his own source code repository, so at the very least it would be more
effort for us to keep our copy up-to-date with his.  python-mode.el doesn't
depend on his code, so it's really not necessary for us to have a copy in our
tree.

As cool as Anton's module is, and it definitely could help Python programmers,
it's probably a better idea to add a reference to his work (and his download
site or source repository) in our README file or in the comments at the top of
python-mode.el.

If Anton really wants us to keep the canonical version of his mode in our bzr
tree, we could discuss that.  Anton, what do you think?

Cheers,
-Barry





___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Error during indentation

[Andreas Röhler]

Am 13.03.2011 12:49, schrieb Andrea Crotti:


I get a strange error when I have a situation like this:
--8<---cut here---start->8---
  1 class Foo(object):
  2 """
  3 Some doc
  4 """
  5 
--8<---cut here---end--->8---
if I go to line 5 and press tab I get the error as below, using:
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of
2011-03-04
and python-mode from bzr (can I get automatically the revision from emacs?)


you may subscribe for mail at

https://code.launchpad.net/~python-mode-devs/python-mode/python-mode

then you will get a mail always the branch is updated

Afterwards do

bzr branch lp:python-mode

BTW : can't reproduce the bug.

Andreas




--8<---cut here---start->8---
Debugger entered--Lisp error: (wrong-type-argument integerp t)
   make-string(1 t)
   py-goto-beginning-of-tqs(t)
   py-compute-indentation(t)
   py-indent-line()
   indent-for-tab-command(nil)
   call-interactively(indent-for-tab-command)
   (progn (setq this-command command) (call-interactively command))
   (if (and (commandp command) (not (string-match "yas/expand" (symbol-name 
command (progn (setq this-command command) (call-interactively command)))
   (when (and (commandp command) (not (string-match "yas/expand" (symbol-name 
command (setq this-command command) (call-interactively command))
   (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 (this-command-keys-vector)) (keys-2 
(and yas/trigger-key from-trigger-key-p (stringp yas/trigger-key) (read-kbd-macro 
yas/trigger-key))) (command-1 (and keys-1 (key-binding keys-1))) (command-2 (and keys-2 
(key-binding keys-2))) (command (or (and (symbolp command-1) (not (string-match 
"yas/expand" (symbol-name command-1))) command-1) (and (symbolp command-2) command-2 
(when (and (commandp command) (not (string-match "yas/expand" (symbol-name command 
(setq this-command command) (call-interactively command)))
   (cond ((eq yas/fallback-behavior (quote return-nil)) nil) ((eq yas/fallback-behavior 
(quote call-other-command)) (let* ((yas/minor-mode nil) (yas/direct-keymaps nil) (keys-1 
(this-command-keys-vector)) (keys-2 (and yas/trigger-key from-trigger-key-p (stringp 
yas/trigger-key) (read-kbd-macro yas/trigger-key))) (command-1 (and keys-1 (key-binding 
keys-1))) (command-2 (and keys-2 (key-binding keys-2))) (command (or (and (symbolp 
command-1) (not ...) command-1) (and (symbolp command-2) command-2 (when (and 
(commandp command) (not (string-match "yas/expand" (symbol-name command 
(setq this-command command) (call-interactively command ((and (listp 
yas/fallback-behavior) (cdr yas/fallback-behavior) (eq (quote apply) (car 
yas/fallback-behavior))) (if (cddr yas/fallback-behavior) (apply (cadr 
yas/fallback-behavior) (cddr yas/fallback-behavior)) (when (commandp (cadr 
yas/fallback-behavior)) (setq this-command (cadr yas/fallback-behavior)) 
(call-interactively (cadr yas/f

all

  back-behavior) (t nil))
   yas/fallback(trigger-key)
   (if (and templates-and-pos (first templates-and-pos)) 
(yas/expand-or-prompt-for-template (first templates-and-pos) (second 
templates-and-pos) (third templates-and-pos)) (yas/fallback (quote 
trigger-key)))
   (let (templates-and-pos) (unless (and yas/expand-only-for-last-commands (not 
(member last-command yas/expand-only-for-last-commands))) (setq 
templates-and-pos (if field (save-restriction (narrow-to-region 
(yas/field-start field) (yas/field-end field)) (yas/current-key)) 
(yas/current-key (if (and templates-and-pos (first templates-and-pos)) 
(yas/expand-or-prompt-for-template (first templates-and-pos) (second 
templates-and-pos) (third templates-and-pos)) (yas/fallback (quote 
trigger-key
   yas/expand()
   call-interactively(yas/expand nil nil)

--8<---cut here---end--->8---
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Error during indentation

[Andreas Röhler]

Am 13.03.2011 21:09, schrieb Andrea Crotti:

Barry Warsaw  writes:


On Mar 13, 2011, at 12:49 PM, Andrea Crotti wrote:


I get a strange error when I have a situation like this:
--8<---cut here---start->8---
 1  class Foo(object):
 2  """
 3  Some doc
 4  """
 5=09
--8<---cut here---end--->8---
if I go to line 5 and press tab I get the error as below, using:
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of
2011-03-04
and python-mode from bzr (can I get automatically the revision from emacs=

?)


I cannot reproduce this with Emacs 23.2.1 on Ubuntu Natty and python-mode=

.el

r400.

-Barry



I thought it was something else interfering, but I've:
- update to rev400
- byte-compiled python-mode
- started a new emacs24 -Q

in the scratch buffer wrote as above, and still the same error...
--8<---cut here---start->8---

Debugger entered--Lisp error: (wrong-type-argument integerp t)
   make-string(1 t)
   (and delim (make-string 1 delim))
   (let ((skip (and delim (make-string 1 delim))) (continue t)) (when skip (=
save-excursion (while continue (py-safe (search-backward skip)) (setq conti=
nue (and (not (bobp)) (=3D (char-before) 92 (if (and (=3D (char-before)=
delim) (=3D (char-before (1- ...)) delim)) (setq skip (make-string 3 delim=
 (py-safe (search-backward skip
   py-goto-beginning-of-tqs(t)


Hi Andrea,

thanks. Have some idea meanwhile wherefrom these bug. It's in the line 
above, resp. it's receiving function.


Ironically you get this bug, because syntax setting is OK now with Emacs 24.

AFAIS bug results, because the delimiting char of a triple-quoted-string 
is no longer of 7, string quote, but of 15, generic string.


syntax-ppss and friends than don't send the delimiting char as integer, 
but `t'. The receiving functions refuses correctly to make a string from:


wrong-type-argument integerp t)

With some luck I'll send a fix next days...

Andreas





   (cond ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipp=
s))) (save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-ba=
ckward "^[ ]*\\([^ \n#]\\|#[   \n]\\)" nil (quote move)) 
(back-to-indentat=
ion) (current-column ((py-continuation-line-p) (let ((startpos (point))=
(open-bracket-pos (py-nesting-level)) endpos searching found state cind cl=
ine) (if open-bracket-pos (progn (setq endpos (py-point (quote bol))) (py-g=
oto-initial-line) (setq cind (current-indentation)) (setq cline cind) (doli=
st (bp (nth 9 ...) cind) (if (search-forward "\n" bp t) (setq cline cind)) =
(goto-char (1+ bp)) (skip-chars-forward "  ") (setq cind (if ... ... ...)))=
) (forward-line -1) (if (py-continuation-line-p) (current-indentation) (end=
-of-line) (setq endpos (point) searching t) (back-to-indentation) (setq sta=
rtpos (point)) (while searching (skip-chars-forward "^=3D" endpos) (if (=3D=
... endpos) (setq searching nil) (forward-char 1) (setq state ...) (if ...=
...))) (if (or (not found) (looking-at "[  ]*")) (progn (goto-char sta=
rtpos) (skip-chars-forward "^  \n"))) (+ (current-column) (if (py-statement=
-opens-block-p) py-continuation-offset 0) 1) ((bobp) (current-indentati=
on)) ((and (looking-at "[  ]*#[^   \n]") (fboundp (quote forward-comment)) (=
<=3D (current-indentation) (save-excursion (forward-comment (- (point-max))=
) (current-indentation (current-indentation)) (t (if (and (eq py-honor-=
comment-indentation nil) (fboundp (quote forward-comment))) (forward-commen=
t (- (point-max))) (let ((prefix-re (concat py-block-comment-prefix "[ ]*"=
)) done) (while (not done) (re-search-backward "^[ ]*\\([^ 
\n#]\\|#\\)" n=
il (quote move)) (setq done (or (bobp) (and ... ...) (and ... ...)) (py=
-goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point (setq plac=
eholder (point)) (py-goto-initial-line) (py-goto-beginning-of-tqs (save-exc=
ursion (nth 3 (parse-partial-sexp placeholder (point) (+ (current-inden=
tation) (if (py-statement-opens-block-p) py-indent-offset (if (and honor-bl=
ock-close-p (py-statement-closes-block-p)) (- py-indent-offset) 0)
   (let* ((bod (py-point (quote bod))) (pps (parse-partial-sexp bod (point))=
) (boipps (parse-partial-sexp bod (py-point (quote boi placeholder) (co=
nd ((or (and (nth 3 pps) (nth 3 boipps)) (and (nth 4 pps) (nth 4 boipps))) =
(save-excursion (if (not py-align-multiline-strings-p) 0 (re-search-backwar=
d "^[  ]*\\([^ \n#]\\|#[   \n]\\)" nil (quote move)) 
(back-to-indentation) =
(current-column ((py-continuation-line-p) (let ((startpos (point)) (ope=
n-bracket-pos (py-nesting-level)) endpos searching found state cind cline) =
(if open-bracket-pos (progn (setq endpos (py-point ...)) (py-goto-initial-l=
ine) (setq cind (current-indentation)) (setq cline cind) (dolist (bp ... ci=
nd) (if ... ...) (goto-char

Re: [Python-mode] running Python tests

[Andreas Röhler]

Am 15.03.2011 04:39, schrieb Yaroslav Halchenko:

Dear Python-mode gurus,

could someone look into adopting at least minimalistic convenience to
run unittests from within emacs? e.g.

https://bitbucket.org/jpellerin/nosemacs

seems to be doing its minimal job just fine



Hi Yaroslav,

thanks pointing to it.

BTW what about joining the team, make a notice as a blueprint, push up 
your branch, propose for merge etc?


We still need a lot of stuff - reasonable auto-completion, refactoring, 
pydb etc.


Pymacs seems broken.

Definitly we should have a specification.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/











___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] Fw: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added

[Andreas Röhler]

Am 15.03.2011 17:23, schrieb Barry Warsaw:

Hi Andreas.  Did you really mean to commit a directory listing as a .el file?
;)

-Barry


OMG, seems something swapped over...
Sorry and thanks.

It's okay at my home board BTW, no magic. Just got the wrong buffer when 
saving.


Andreas




Begin forwarded message:

Date: Tue, 15 Mar 2011 11:11:16 -
From: nore...@launchpad.net
To: Barry Warsaw
Subject: [Branch ~python-mode-devs/python-mode/python-mode] Rev 402: 
py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added



revno: 402
committer: Andreas Roehler
branch nick: python-mode
timestamp: Tue 2011-03-15 11:08:05 +0100
message:
 py-goto-beginning-of-tqs-lp:735328-test with py-bug-numbered-tests.el added
added:
   py-bug-numbered-tests.el


--
lp:python-mode
https://code.launchpad.net/~python-mode-devs/python-mode/python-mode

Your team python-mode.el developers is subscribed to branch lp:python-mode.
To unsubscribe from this branch go to 
https://code.launchpad.net/~python-mode-devs/python-mode/python-mode/+edit-subscription



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] apropos py-bug-numbered-tests

[Andreas Röhler]

Hi Barry,

test concerning last bug report
`goto-beginning-of-tqs-lp:735328-test' should go
through with python-mode.el, some others too, but not
all.

To tackle remaining bugs, would
change some lisp of python-mode.el towards more common
forms. For example `py-save' now is as macro
`ignore-errors' available.

Also `py-point' forms IMHO rather obfuscate the code. Did
see the explanation for it, but don't think it pays.

Do I have green light for such a clean up?

Would commit every logical step, so it should be easy to
revert, should some mistake occur.

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] apropos py-bug-numbered-tests

[Andreas Röhler]

Am 15.03.2011 21:09, schrieb Barry Warsaw:

On Mar 15, 2011, at 07:47 PM, Andreas Röhler wrote:


To tackle remaining bugs, would
change some lisp of python-mode.el towards more common
forms. For example `py-save' now is as macro
`ignore-errors' available.


The question is cross-Emacsen compatibility, and also compatibility with older
Emacsen.  E.g. how far back does ignore-errors support and does it work with
XEmacs?


21.5 says:

`ignore-errors' is a compiled Lisp macro
  -- loaded from "cl-macs"
(ignore-errors &rest BODY)

Documentation:
Execute BODY; if an error occurs, return nil.
Otherwise, return result of last form in BODY.

;;;

That should work.

BTW in cases, XEmacs misses a form, think it's better to implement it 
for XE as we have done, rather than maintain python-mode specific forms.





Also `py-point' forms IMHO rather obfuscate the code. Did
see the explanation for it, but don't think it pays.


I do like py-point a lot.


Sure :-)

Code was more verbose without it, so I do think it

helps, and should be pretty easy to understand.  OTOH, I guess you're doing
the most work on the code now, so you get to decide.  However I wouldn't
necessarily recommend ripping it all out (IOW, "if it ain't broke, don't fix
it").


Do I have green light for such a clean up?


I'll leave it up to you, with the above caveats.


Listen, Barry: the code is intrinsic for me to an extend, that I don't 
know how to fix the remaining bugs mentioned. All these bugs are absent 
in the components branch, because it's simplified from the scratch - 
more or less...


Tried to backport some solution and could resolve some issues. But again 
and again going trapped into some wire.


Obviously no one else could solve that over the years also. That's not a 
surprise. We are in some labyrinth, before some gordic knots.


OTOH it's a pleasure for me to see solutions from different sides, 
python.el, components- and python-mode. So if you permit, will try to 
range things still.


Tell if cannot bear it any longer :-)

Andreas




Would commit every logical step, so it should be easy to
revert, should some mistake occur.


Maybe getting the tests working first would be a good idea?  That way, you
have some baseline to prove that your changes aren't breaking the code.  What
do you think?

-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] r401 is broken

[Andreas Röhler]

Am 15.03.2011 22:21, schrieb Barry Warsaw:

Hi Andreas,

r401 broke TAB indentation in Emacs 23.  In the attached file, set the cursor
at the end of line 48, then hit return and tab.  Point does not indent.

Cheers,
-Barry




there was a typo, done now.
Will see again tomorrow.
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight-indentation

[Andreas Röhler]

Am 14.03.2011 10:04, schrieb Anton Johansson:

Hi, if you can forward bug tracking automatically, please do,



Hi,

launchpad sends notifications once a bug is tracked there. Must be 
registered, which goes smoothly, no special requirings.


With an lp account I may subscribe to related bugs. Also you may 
subscribe yourself to what matter whatever and do some other funny things.


Beside bug-tracking feature-request may be tracked. Blue-prints are for 
that AFAIU.


Than it has Milestones where ToDo's might be listed and Releases prepared.

highlight-indentation integration could be part of a milestone for example.

So far

best regards,

Andreas


otherwise it's ok don't overwork it :) Also the full functionality of 
highlight-indentation is basically:


(setq highlight-indent-offset 4) ;; Spaces indent level
(font-lock-add-keywords nil `((,(format "\\( \\) \\{%s\\}" (- 
highlight-indent-offset 1)) (1 'highlight-indent-face

so if you find a better place to extract that to syntax highlighting code it 
might be better...

Cheers
-- Anton

On Mar 13, 2011, at 09:15 , Andreas Röhler wrote:


Hi Anton,

thanks a lot BTW.

Added a link onto your repo into the header.

In order to get a wider audience with resp. to other modes an entry
at

http://www.emacswiki.org/emacs-en

might be useful.


As for bug-tracking think we should forward any report to you, if it concerns 
your file(s). OTOH would not charge the users which such specific requests.

Agreed?

Thanks again.


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/




Am 12.03.2011 11:38, schrieb Anton Johansson:

Hello,

I'm absolutely cool with you guys using the code in any way you find
suitable, nice to see some people finding it useful!

Like you have discussed before, there are some issues with
highlight-indentation.el that could be handled better, for example
highlighting spaces that are not in the leading whitespace. If you can
find a good way to link to my repo so that people can submit possible
fixes that would be good since the code is also usable in other modes.

Cheers
-Anton

On Sat, Mar 12, 2011 at 4:28 AM, Barry Warsaw   wrote:

Hi Andreas,

I noticed that you committed this file to our bzr tree.  I'm concerned about
doing this without Anton's approval (and maybe even with it).  Anton probably
has his own source code repository, so at the very least it would be more
effort for us to keep our copy up-to-date with his.  python-mode.el doesn't
depend on his code, so it's really not necessary for us to have a copy in our
tree.

As cool as Anton's module is, and it definitely could help Python programmers,
it's probably a better idea to add a reference to his work (and his download
site or source repository) in our README file or in the comments at the top of
python-mode.el.

If Anton really wants us to keep the canonical version of his mode in our bzr
tree, we could discuss that.  Anton, what do you think?

Cheers,
-Barry










___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] bug lp:328842, flexible-indentation of multiline assignements

[Andreas Röhler]

Hi Barry, hi all,

while considering the request valid, even if the current
non-indent is an option,

what's the recommendable indent?

Would not choose the block-indent step, rather signal
it's something different at stake.

What about indenting it to the end of first element of
previous line?

;;;
(longer, sequence, of_items,
   that, needs, to_be, wrapped) = input_list

packed_entry = (long, sequence, of_items,
that, needs, to_be, wrapped)
;;

Would introduce two boolean variables

py-multiline-assignement-first-column:

"If a multiline-assignement element in first-column
should be indented"

py-multiline-indent-to-first-element:

"If a multiline-assignement in first-column
should be indented to the end of it's first element. "

Also:

(defcustom py-indent-in-delimiter 1
  "When inside a multiline-assignement: How many colums indent should 
be more than opening bracket, brace or parenthesis. "

  :type 'integer
  :group 'python)
(make-variable-buffer-local 'py-indent-in-delimiter)


Cheers

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight-indentation

[Andreas Röhler]

Am 14.03.2011 17:49, schrieb Barry Warsaw:

@pycon so just a quick reply...

On Mar 12, 2011, at 01:44 PM, Andreas Röhler wrote:


As for the approval: thought that's precisely what the
GPL is for.


Well, the GPL makes it *legal*, but approval keeps us nice. :)

-B


Hi Barry,

makes me some headache, will see if I'm able to explain the --in the 
precise case purely abstract-- reasons:


First at the GPL:

its often blamed and disputed and has some quirks. But seen from the 
world outside it provides indeed some miraculous, which you may call 
freedom. BTW I'm not going to relate it to other licences providing free 
software, just the phenomen Emacs and GPL at stake here.


GPL just works, it provides permissions to use, change, distribute etc.

Lets further assume any person publishing code under GPL knows what it's 
doing.


If not, we should not try to fix that by extra personal permissions 
handed over, but by teaching the meaning of the GPL.


OTOH if someone is going to state obvious things, these statements 
change its meaning.


Same when asking questions already answered.

The danger here is raising wrong expectations.

If you ask for a use, did you ask for a permission to change too?

What, if the author later changes it's mind?
Will you pull the code than out again?

See diskussions lately around python.el, what kind of difficulties may 
arise, when confidence in GPL should not be enough.


Nonetheless always trying to be as polite as my habits permit... :-)

Cheers

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/














___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements

[Andreas Röhler]

Am 25.03.2011 14:07, schrieb s...@pobox.com:


 Andreas>  What about indenting it to the end of first element of previous
 Andreas>  line?

That is precisely the problem.  That's what it does today, and if the lhs of
the assignment is a complex expression, the continuation is indented way too
far.  I would much prefer just to simply indent by the normal block indent.

Skip



Hi Skip,

I'll introduce a defcustom for that

just set

`py-multiline-indent-to-first-element'

--or however it will be called finally--

onto the value you prefer.

Default will be 2 probably, just my taste, but that may change. :-)

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements

[Andreas Röhler]

Am 25.03.2011 14:35, schrieb Andreas Röhler:

Am 25.03.2011 14:07, schrieb s...@pobox.com:


Andreas> What about indenting it to the end of first element of previous
Andreas> line?

That is precisely the problem. That's what it does today, and if the
lhs of
the assignment is a complex expression, the continuation is indented
way too
far. I would much prefer just to simply indent by the normal block
indent.

Skip



Hi Skip,

I'll introduce a defcustom for that

just set

`py-multiline-indent-to-first-element'



Sorry,

that's my mistake.

Thats will be boolean, as it's name says.

When indenting to common indent-offset,

use the defcustom  than created for that purpose.
`py-multiline-indent-to-first-element' must be nil than,

as the indent of the first element shouldn't matter.


Andreas



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] highlight-indentation

[Andreas Röhler]

Am 25.03.2011 16:08, schrieb Barry Warsaw:

Hi Andreas,

I don't disagree with anything you wrote, and of course we're allowed to use
anything GPL'd.  I don't think even politeness mandates pre-approval in order
to *use* GPL code.

The "let's be nice" comment wasn't directed at you personally, or really
anybody here - I think we're all being nice, helpful, and polite, which to me
is one of the most important principles of FLOSS. :)

It also wasn't a comment on our use of GPL code.  It was related to our
bringing in a copy of someone else's file, which is already under their own
VCS, into our VCS.  Doing so could give the impression that we're the
authoritative copy of the file.  I wouldn't want to usurp someone else's
authority on that without their approval.

I hope that makes sense.


Me too :-)

Somehow the VCS seems at stake now.
Okay, let's go on. Thanks and sorry should I have provoked too much writing.

Let's go into another turn.

Andreas





Cheers,
-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements

[Andreas Röhler]

Am 25.03.2011 16:54, schrieb Barry Warsaw:

On Mar 25, 2011, at 09:51 AM, Andreas Röhler wrote:


while considering the request valid, even if the current
non-indent is an option,

what's the recommendable indent?

Would not choose the block-indent step, rather signal
it's something different at stake.

What about indenting it to the end of first element of
previous line?

;;;
(longer, sequence, of_items,
that, needs, to_be, wrapped) = input_list

packed_entry = (long, sequence, of_items,
 that, needs, to_be, wrapped)
;;


I must be missing something because these two snippets get indented like this
for me, running r405:

-snip snip-
(longer, sequence, of_items,
  that, needs, to_be, wrapped) = input_list

packed_entry = (long, sequence, of_items,
 that, needs, to_be, wrapped)
-snip snip-

which seems exactly right to me!



Noticed.

As different styles are possible, think we can deliver what has been 
requested for.





If you do introduce a variable to control this, please do retain the current
behavior as default.


Okay.

Would help having an appropriate name for these indents.

What about calling the first an `left-inbound indent' --default will be 
1--, the second `right-inbound-indent' --default will be (1+ column of 
opening parentesis)--





Cheers,
-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] bug lp:328842, flexible-indentation of multiline assignements

[Andreas Röhler]

Am 25.03.2011 19:32, schrieb s...@pobox.com:

I find this indentation truly grating:

 self.last_abc_attr = self.last_xyz_attr = \
  self.last_abc_other = \
  self.last_xyz_other = None

Now, I can move self.last_xyz_attr to a continuation line, but though the
result is slightly different, it is, in my opinion, just as bad:

 self.last_abc_attr = \
self.last_xyz_attr = \
self.last_abc_other = \
self.last_xyz_other = None

What I would like to see is this (given a four-space block indent):

 self.last_abc_attr = \
 self.last_xyz_attr = \
 self.last_abc_other = \
 self.last_xyz_other = None

or, if the second expression remained on the first line:

 self.last_abc_attr = self.last_xyz_attr = \
 self.last_abc_other = \
 self.last_xyz_other = None

I don't care if this behavior is the default.  I just want to be able to
control it.  Currently, I have to manually format lines like this, and if
I'm not careful and reindent an entire function or file, then python-mode
undoes my work.

Skip



Hi Skip,

think that may be done.

As it's a different thing though than indenting inside tuples, lists etc.,
would you mind making a bug entry giving your last examples?

Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

[Python-mode] myrkwid ready to merge?

[Andreas Röhler]

Hi Barry,

AFAIS all indent-bugs reported are done with Myrkwid branch.

Provided tests from inside Emacs for it: py-bug-numbered-tests.el

Also tests may be run in batch-mode: python-mode-tests.sh

Please have a look if it's ready:

https://code.launchpad.net/~a-roehler/python-mode/myrkwid

The core is re-written, so would not merge without your consent.

API however should be unchanged, beside some extra delivered.

Functions moving point are designed around
  `py-beginning-of-statement', `py-end-of-statement'

with `py-travel-current-indent' stepping downwards.

Also `py-compute-indentation' redone.

Cheers

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] myrkwid ready to merge?

[Andreas Röhler]

Am 28.03.2011 16:55, schrieb Barry Warsaw:

On Mar 26, 2011, at 07:08 PM, Andreas Röhler wrote:


AFAIS all indent-bugs reported are done with Myrkwid branch.

Provided tests from inside Emacs for it: py-bug-numbered-tests.el

Also tests may be run in batch-mode: python-mode-tests.sh

Please have a look if it's ready:

https://code.launchpad.net/~a-roehler/python-mode/myrkwid


The diff is pretty big, but I'll try to find some time to review the
python-mode.el parts.


its just the move-, mark parts which have changed. The diff is confusing.

 In the meantime, I'll grab your branch and use it for a

few days.  Before it gets merged, I think Skip should definitely do the same
to test for XEmacs compatibility.


If XEmacs tqs-syntax is still broken, he will not have more fun than 
with the trunk.


XEmacs users for now should be best off with components branch. Might 
remain  some dependencies still to solve, but the basics for non-pps 
parsing are available.


Should Skip report XEmacs related bugs of components branch, I'm ready 
to implement the missing parts - cc to him.


Cheers



Cheers,
-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] myrkwid ready to merge?

[Andreas Röhler]

Am 29.03.2011 20:36, schrieb Barry Warsaw:

Andreas, when I find problems with the myrkwid branch, do you want me to
mention them here or submit bug reports?  Here's the first problem I've
noticed.

Open up Python 3.3's setup.py (i.e. on the mercurial default branch).  Go to
the end of line 371, which is on the return statement (last line) of the
get_platform() method.  Hit return.  This puts you on a new line, but at
column 12.  The first problem is that that should really indent to column 4
because of the preceding return statement.


See it. Added a bug-report.

Thanks again.

Andreas



Now that you're in col 12, hit delete or backspace.  This should move the
indentation back one level each time, but instead it doesn't move at all,
although you do get a message in the echo.

Gotta fix that before it's merged to trunk! ;)

Cheers,
-Barry



___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el cleanup

[Andreas Röhler]

Am 30.03.2011 04:58, schrieb Christoph Scholtes:

Stefan Monnier  writes:


Could you just clarify why they're considered obsolete (e.g. what would
the user use instead)?


`python-shell' is not needed since Dave's mode already had
'run-python' to invoke the python interpreter. It offers no advantages
over run-python as far as I can tell except being able to toggle
between a Python and a Jython shell (see below for comments on that).

`python-comint-filter-function' is only called from `python-shell'.

`python-file-queue' is never populated anywhere, only read from
`python-comint filter-function'.

`python-default-interpreter' is only used by `python-shell' and not,
as advertised in its documentation, on first visiting a Python mode
buffer.

`python-python-command-args' and `python-jython-command-args' are only
used in the `python-toggle-shell' function.

`python-which-shell', `python-which-args' and `python-which-bufname'
are used for toggling between the Python and Jython shell.

Finally, `python-toggle-shell'. I think, that we should provide a better
solution for this and therefore remove the current implementation. This
code came from python-mode.el, if I traced that back right.



Hi Christoph,

glad to see Emacs python facilities improve. As you mention 
python-mode.el, there are some remarks in python.el which I feel are not 
correct. If some solution predates historically another, there are 
usually some setbacks from being the first.


OTOH from my perspective python-mode.el has still some point in proceding.

Hopefully we may discuss the pro and cons to the benefit of users, which 
flavour they may choose finally. As you might have been remarked, its 
interwoven to an extend, you can seldom discern it clearly to the one or 
other origin.


BTW I'm not blaming the GNU's side. Just wanted to point at the issue so 
we might hopefully reduce the obstacles.


Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/






Python interpreter selection should be universal and not only support Jython
and CPython, but also IronPyton, PyPy etc. I would like to implement a
better solution for this as soon as Fabian's changes are installed. I am
using IronPython quite a bit and it would be nice to be able to switch
flexibly between different interpreters.

Christoph




___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] myrkwid ready to merge?

[Andreas Röhler]

[ ... ]

Hi Barry,

added still another python-mode-test.el, running
test-cases independently from bugs reported:

`py-run-tests' does for now

 'py-beginning-of-block-test
 'py-end-of-block-test
 'py-beginning-of-block-or-clause-test
 'py-end-of-block-or-clause-test
 'py-beginning-of-def-test
 'py-end-of-def-test
 'py-beginning-of-def-or-class-test
 'py-end-of-def-or-class-test

Please tell, if there are cases you want to see.

Cheers

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] myrkwid bug with backspace/delete

[Andreas Röhler]

Am 31.03.2011 17:36, schrieb Barry Warsaw:

Hi Andreas,

myrkwid branch still has a minor problem.

-snip snip-
class Foo:
 def foo(self):
 pass
-snip snip-

Put point at the end of the 'pass' line.

Hit return.  Indentation is correct.  However backspace/delete never moves.

Cheers,
-Barry



Thanks, erorr is in py-electric-backspace.

Will re-write and simplify it to

"Delete preceding character or level of indentation.
With arg do it arg times."

Unless you object.. :)

Cheers

Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] myrkwid bug with backspace/delete

[Andreas Röhler]

Am 31.03.2011 17:36, schrieb Barry Warsaw:

Hi Andreas,

myrkwid branch still has a minor problem.

-snip snip-
class Foo:
 def foo(self):
 pass
-snip snip-

Put point at the end of the 'pass' line.

Hit return.  Indentation is correct.  However backspace/delete never moves.

Cheers,
-Barry





Hi Barry,

checked in fixes.
Also cured a mistake of 745208'-fix, where python- and emacs-lisp logic 
has been came across...


Cheers

Andreas

___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] myrkwid bug with backspace/delete

[Andreas Röhler]

Am 01.04.2011 21:58, schrieb Barry Warsaw:

On Apr 01, 2011, at 12:31 PM, Andreas Röhler wrote:


checked in fixes.  Also cured a mistake of 745208'-fix, where python- and
emacs-lisp logic has been came across...


Thanks Andreas!  Things are looking better, but still not quite perfect. ;)

-snip snip-
def foo():
 a = bar(one=1,
 two=2,
 three=3)
-snip snip-

Put point at the closing parenthesis and hit return.  You get lined up under
the 't' in 'three' whereas you should be lined up under the 'a'.


Hi Berry,

it's lined below `t' indicating the multiline character.

I'm afraid we are here in a sphere, were people will ask for different 
styles.


Unless I miss something.

What about storing that as a bug report and coming back at a later time?

BTW after merge would adress the execute/shell/unicode errors.

OTOH if you think it must be now it will be now... :-)

Cheers

Andreas




Cheers,
-Barry


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode