From andreas.roehler at online.de Thu Sep 3 13:32:01 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Thu, 03 Sep 2009 13:32:01 +0200 Subject: [Python-mode] [Merge] lp:~freiksenet/python-mode/hide-show-support into lp:python-mode In-Reply-To: <20090902203020.11340.7280.launchpad@loganberry.canonical.com> References: <20090902203020.11340.7280.launchpad@loganberry.canonical.com> Message-ID: <4A9FA931.9070405@online.de> Mikhail Novikov wrote: > Mikhail Novikov has proposed merging lp:~freiksenet/python-mode/hide-show-support into lp:python-mode. > > Requested reviews: > python-mode.el developers (python-mode-devs) > > I have improved it to support more constructs and docstrings. Works fine for me, more testing is needed. > > Some versions of emacs introduced bug to hideshow that makes this work badly. Hideshow.el from emacs trunk works fine. > > Hideshowviz.el conflicts with python-mode because it implements own mod-map. To fix it comment out mode-map enable line in hideshowviz mode enable and add global keybinding hooked to hs-minor-mode to get the keybinding introduced in hideshowviz back. > Hi Mikhail, seeing you changed regexp inside `hs-special-modes-alist': good idea IMO, works fine. Nonetheless let's raise some questions: Concerning `hs-block-start-regexp': people may have different opinions what to hide. What about to make this customizable? After this: do you need (unless (assoc 'python-mode hs-special-modes-alist) I.e. why not set the value always if python-mode is called? Cheers Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ From rohan.nicholls at googlemail.com Tue Sep 8 10:43:45 2009 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Tue, 8 Sep 2009 10:43:45 +0200 Subject: [Python-mode] looking for a discussion of things python(-mode) ish Message-ID: Hi all, I was looking for information about ptyhon.el and ipython.el and have started making ipython work with python.el, when I stumbled on the consolidation attempt of the two modes. I checked out the python-mode launchpad project, and am now sending an email. Do I need to sign up to the python mailing list to see any discussions? Or does this email get me added to some secret list? ;) I am very interested in getting everything under one roof, although the discussion I read in January seems to indicate that this will never be. Just to sum up reasons that I had started using python.el - python-mode had shown no sign of life for about 5 years - The killer was the triple quote bug. I was horribly stung by this, and at that point tossed python-mode even though the integration with ipython.el is hard to beat. - I am an emacs user, having given up on xemacs a couple of years ago, and it shows no sign of improving, so emacs specificity is not a problem for me, in fact it is a plus, as the various incompatible bits of the two systems do not start clogging up the code. So my questions are: - Is the triple quote threat solved in python-mode (because it is in python.el) - It seems development has started up again, would this be correct, and is there a list of things to fix somewhere? Also has Beverley Eyre compiled that list of features she mentioned back in January? Please reply to me directly, esp. about a python-mode mailing list, so I can sign up. Thanks in advance for info. :) Rohan From barry at python.org Tue Sep 8 14:37:14 2009 From: barry at python.org (Barry Warsaw) Date: Tue, 8 Sep 2009 08:37:14 -0400 Subject: [Python-mode] looking for a discussion of things python(-mode) ish In-Reply-To: References: Message-ID: <4260D065-4AAA-4A6F-B43C-7F2EDD30E280@python.org> On Sep 8, 2009, at 4:43 AM, Rohan Nicholls wrote: > I checked out the python-mode launchpad project, and am now sending an > email. Do I need to sign up to the python mailing list to see any > discussions? Or does this email get me added to some secret list? ;) While I approved your message, you should explicitly join here http://mail.python.org/mailman/listinfo/python-mode > I am very interested in getting everything under one roof, although > the discussion I read in January seems to indicate that this will > never be. > > Just to sum up reasons that I had started using python.el > - python-mode had shown no sign of life for about 5 years That's changed now. > - The killer was the triple quote bug. I was horribly stung by this, > and at that point tossed python-mode even though the integration > with ipython.el is hard to beat. I personally am rarely enough bitten by this to care, but I would love to have someone port python.el's approach to python-mode.el. IIRC, python.el uses regexps and python-mode.el uses the syntax table. The syntax table has the advantage of being much faster, which mattered a lot at one time, but it's not flexibly enough to handle Python's quoting rules. > - I am an emacs user, having given up on xemacs a couple of years > ago, and it shows no sign of improving, so emacs specificity is not > a problem for me, in fact it is a plus, as the various incompatible > bits of the two systems do not start clogging up the code. python-mode.el works just fine in both Emacs and XEmacs. > So my questions are: > - Is the triple quote threat solved in python-mode (because it is in > python.el) I don't believe it has ever been ported over. > - It seems development has started up again, would this be correct, > and is there a list of things to fix somewhere? Also has Beverley > Eyre compiled that list of features she mentioned back in January? Yes, it's being actively developed, but my sense of it is that python- mode.el pretty much works well for everyone using it, so I wouldn't say there's a ton of itches that need scratching. We add support for new syntax every time a new Python version comes out. It's probably not as Python 3.x friendly as it should be. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Wed Sep 9 11:56:51 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Wed, 09 Sep 2009 11:56:51 +0200 Subject: [Python-mode] looking for a discussion of things python(-mode) ish In-Reply-To: <4260D065-4AAA-4A6F-B43C-7F2EDD30E280@python.org> References: <4260D065-4AAA-4A6F-B43C-7F2EDD30E280@python.org> Message-ID: <4AA77BE3.3020205@online.de> Barry Warsaw wrote: > On Sep 8, 2009, at 4:43 AM, Rohan Nicholls wrote: > >> I checked out the python-mode launchpad project, and am now sending an >> email. Do I need to sign up to the python mailing list to see any >> discussions? Or does this email get me added to some secret list? ;) > > While I approved your message, you should explicitly join here > > http://mail.python.org/mailman/listinfo/python-mode > >> I am very interested in getting everything under one roof, although >> the discussion I read in January seems to indicate that this will >> never be. >> >> Just to sum up reasons that I had started using python.el >> - python-mode had shown no sign of life for about 5 years > > That's changed now. > >> - The killer was the triple quote bug. I was horribly stung by this, >> and at that point tossed python-mode even though the integration >> with ipython.el is hard to beat. > > I personally am rarely enough bitten by this to care, but I would love > to have someone port python.el's approach to python-mode.el. IIRC, > python.el uses regexps and python-mode.el uses the syntax table. Hi, checking for the triple-quoted-bug: with python.el, (nth 8 (syntax-ppss)) shows the correct result. Unfortunately with python-mode.el (nth 8 (syntax-ppss)) fails. >From there I assume, setting the syntax-table properly might solve the bug Cheers Andreas The > syntax table has the advantage of being much faster, which mattered a > lot at one time, but it's not flexibly enough to handle Python's quoting > rules. > >> - I am an emacs user, having given up on xemacs a couple of years >> ago, and it shows no sign of improving, so emacs specificity is not >> a problem for me, in fact it is a plus, as the various incompatible >> bits of the two systems do not start clogging up the code. > > python-mode.el works just fine in both Emacs and XEmacs. > >> So my questions are: >> - Is the triple quote threat solved in python-mode (because it is in >> python.el) > > I don't believe it has ever been ported over. > >> - It seems development has started up again, would this be correct, >> and is there a list of things to fix somewhere? Also has Beverley >> Eyre compiled that list of features she mentioned back in January? > > Yes, it's being actively developed, but my sense of it is that > python-mode.el pretty much works well for everyone using it, so I > wouldn't say there's a ton of itches that need scratching. We add > support for new syntax every time a new Python version comes out. It's > probably not as Python 3.x friendly as it should be. > > -Barry > > > ------------------------------------------------------------------------ > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From barry at python.org Wed Sep 9 12:50:31 2009 From: barry at python.org (Barry Warsaw) Date: Wed, 9 Sep 2009 06:50:31 -0400 Subject: [Python-mode] looking for a discussion of things python(-mode) ish In-Reply-To: <4AA77BE3.3020205@online.de> References: <4260D065-4AAA-4A6F-B43C-7F2EDD30E280@python.org> <4AA77BE3.3020205@online.de> Message-ID: <5109FEBF-4C6A-4ADC-BB7C-1D3C54E178F6@python.org> On Sep 9, 2009, at 5:56 AM, Andreas Roehler wrote: > checking for the triple-quoted-bug: > > with python.el, > > (nth 8 (syntax-ppss)) shows the correct result. > > Unfortunately with python-mode.el (nth 8 (syntax-ppss)) fails. > > From there I assume, setting the syntax-table properly > might solve the bug I haven't looked at this stuff in ages. Has the syntax table grown more support for the kind of things Python's triple quoted strings needs? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Thu Sep 10 11:29:24 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Thu, 10 Sep 2009 11:29:24 +0200 Subject: [Python-mode] looking for a discussion of things python(-mode) ish In-Reply-To: <5109FEBF-4C6A-4ADC-BB7C-1D3C54E178F6@python.org> References: <4260D065-4AAA-4A6F-B43C-7F2EDD30E280@python.org> <4AA77BE3.3020205@online.de> <5109FEBF-4C6A-4ADC-BB7C-1D3C54E178F6@python.org> Message-ID: <4AA8C6F4.8090405@online.de> Barry Warsaw wrote: > On Sep 9, 2009, at 5:56 AM, Andreas Roehler wrote: > >> checking for the triple-quoted-bug: >> >> with python.el, >> >> (nth 8 (syntax-ppss)) shows the correct result. >> >> Unfortunately with python-mode.el (nth 8 (syntax-ppss)) fails. >> >> From there I assume, setting the syntax-table properly >> might solve the bug > > I haven't looked at this stuff in ages. Has the syntax table grown more > support for the kind of things Python's triple quoted strings needs? > > -Barry > Hi Barry, after (put-text-property TRIPLE-QUOTE-START-LAST-CHAR-POS TRIPLE-QUOTE-END-FIRST-CHAR-POS 'py-mode-syntax-table '(15 . 34)) doublequotes may be inserted inside triple quoted string - no fontification-bug then. Similar thing in python.el AFAIU. Strange thing I don't understand in context with checks inside triple quoted string (TQS): text-properties-at -> (face font-lock-string-face py-mode-syntax-table (15 . 34) fontified t) But (syntax-after pos) inside returns different syntax-classes, (7) or (2) Does it query an underlying syntax-table? Below my test-text.py, triple quoted string starts at pos 330 Used (put-text-property 330 347 'py-mode-syntax-table '(15 . 34)) Probably the right thing is: (put-text-property (copy-marker 330) (copy-marker 347) 'py-mode-syntax-table '(15 . 34)) Cheers Andreas ;;;;;;;;;;;;;; #! /usr/bin/env python # -*- coding: utf-8 -*- """ """ import re, sys, os, pdb, random, time import MySQLdb from urllib2 import Request, urlopen, URLError, HTTPError # Get the command line arguments args = sys.argv # pdb.set_trace() # Get the name of the file to count the words in filename = args[1] def usage(): print """Usage: %s .... """ % ( os.path.basename(sys.argv[0])) def main(): if len(sys.argv)==1: usage() sys.exit() if __name__=="__main__": main() ;;;;;;;; From andreas.roehler at online.de Thu Sep 10 13:54:53 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Thu, 10 Sep 2009 13:54:53 +0200 Subject: [Python-mode] triple-quoted-string bug fixed Message-ID: <4AA8E90D.8030009@online.de> Hi Barry, diff attached against latest python-mode.el solves bug 328790, the triple string bug for me - checked with X- and GNU Emacs. Took some stuff from python.el, thanks towards its excellent author BTW. Did create a branch for it. Log now reads revno: 352 committer: Andreas Roehler branch nick: python-mode timestamp: Thu 2009-09-10 13:30:24 +0200 message: --fixes=lp:328790 Should I try bzr push lp:~a-roehler/python-mode/triple-quoted-string-bug-328790.el ? Cheers Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: python-mode-tqs-bug.diff Type: text/x-patch Size: 12168 bytes Desc: not available URL: From andreas.roehler at online.de Thu Sep 10 19:43:07 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Thu, 10 Sep 2009 19:43:07 +0200 Subject: [Python-mode] triple-quoted-string bug fixed (2) Message-ID: <4AA93AAB.2060209@online.de> Hi, had to move `py-mode-syntax-table' still upward in file. Now no complaining any more. Thanks being patient... Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: 2_python-mode-tqs-bug.diff Type: text/x-patch Size: 12168 bytes Desc: not available URL: From rohan.nicholls at googlemail.com Thu Sep 10 20:13:12 2009 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Thu, 10 Sep 2009 20:13:12 +0200 Subject: [Python-mode] triple-quoted-string bug fixed In-Reply-To: <4AA8E90D.8030009@online.de> References: <4AA8E90D.8030009@online.de> Message-ID: Damn, that was fast. Thanks. On Thu, Sep 10, 2009 at 1:54 PM, Andreas Roehler wrote: > > Hi Barry, > > diff attached against latest python-mode.el solves bug > 328790, the triple string bug for me - checked > with X- and GNU Emacs. > > Took some stuff from python.el, thanks towards its > excellent author BTW. > > Did create a branch for it. Log now reads > > revno: 352 > committer: Andreas Roehler > branch nick: python-mode > timestamp: Thu 2009-09-10 13:30:24 +0200 > message: > ?--fixes=lp:328790 > > > Should I try > > bzr push lp:~a-roehler/python-mode/triple-quoted-string-bug-328790.el > > ? > > Cheers > > Andreas > > > From barry at python.org Fri Sep 11 17:34:16 2009 From: barry at python.org (Barry Warsaw) Date: Fri, 11 Sep 2009 11:34:16 -0400 Subject: [Python-mode] triple-quoted-string bug fixed In-Reply-To: <4AA8E90D.8030009@online.de> References: <4AA8E90D.8030009@online.de> Message-ID: <8849081C-2CA1-4A7D-A3C7-7545AED4BB21@python.org> On Sep 10, 2009, at 7:54 AM, Andreas Roehler wrote: > Hi Barry, > > diff attached against latest python-mode.el solves bug > 328790, the triple string bug for me - checked > with X- and GNU Emacs. > > Took some stuff from python.el, thanks towards its > excellent author BTW. > > Did create a branch for it. Log now reads > > revno: 352 > committer: Andreas Roehler > branch nick: python-mode > timestamp: Thu 2009-09-10 13:30:24 +0200 > message: > --fixes=lp:328790 > > > Should I try > > bzr push lp:~a-roehler/python-mode/triple-quoted-string-bug-328790.el Hi Andreas, thanks for the patch! If you're up for it, I'd love to use Launchpad's merge proposals to handle this. * push the branch to launchpad * link the branch to the bug [1] * submit a merge proposal for the branch [1] You can do this from bzr with: bzr commit --fixes=lp:328790 though you might need to include --unchanged if all your changes are already committed. If you do use --fixes, do this before you push. After a short delay, LP will automatically link your branch to the bug. Let me know if you have any questions. You can assign the merge proposal to me and I will get an email notification. We'll handle it from there. Thanks! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Fri Sep 11 21:55:20 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 11 Sep 2009 21:55:20 +0200 Subject: [Python-mode] triple-quoted-string bug fixed (3) Message-ID: <4AAAAB28.7070406@online.de> Hi, as it turns out, assumed fix was wrong as far it concerns XEmacs. Change only works for GNU Emacs. Will see. Cheers Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Fri Sep 11 22:34:43 2009 From: barry at python.org (Barry Warsaw) Date: Fri, 11 Sep 2009 16:34:43 -0400 Subject: [Python-mode] triple-quoted-string bug fixed (3) In-Reply-To: <4AAAAB28.7070406@online.de> References: <4AAAAB28.7070406@online.de> Message-ID: <77A259D4-6638-4C70-9877-CB8029BA8763@python.org> On Sep 11, 2009, at 3:55 PM, Andreas Roehler wrote: > as it turns out, assumed fix was wrong > as far it concerns XEmacs. > > Change only works for GNU Emacs. > > Will see. Cool, thanks. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Sun Sep 13 12:29:28 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 13 Sep 2009 12:29:28 +0200 Subject: [Python-mode] beginning-of-defun-function.patch Message-ID: <4AACC988.4050705@online.de> Hi, as mentioned, several modes like C++ or python-mode need a more sophisticated determination of beginning- or end-of-defun than a regexp may provide. A additional function-call will be possible with patch attached. It allows use of `M-x end-of-defun' in python-mode for example. Should no one object, I'll try to check it in into the mercurial repo. Cheers Andreas R?hler -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ -------------- next part -------------- A non-text attachment was scrubbed... Name: beginning-of-defun-function.patch Type: text/x-patch Size: 2653 bytes Desc: not available URL: From barry at python.org Mon Sep 14 02:04:22 2009 From: barry at python.org (Barry Warsaw) Date: Sun, 13 Sep 2009 20:04:22 -0400 Subject: [Python-mode] beginning-of-defun-function.patch In-Reply-To: <4AACC988.4050705@online.de> References: <4AACC988.4050705@online.de> Message-ID: <94EA68FA-47EE-46E7-AF69-BBFE41441F03@python.org> On Sep 13, 2009, at 6:29 AM, Andreas Roehler wrote: > as mentioned, several modes like C++ or python-mode > need a more sophisticated determination of beginning- > or end-of-defun than a regexp may provide. > > A additional function-call will be possible with patch > attached. It allows use of `M-x end-of-defun' in > python-mode for example. > > Should no one object, I'll try to check it in into > the mercurial repo. I think you meant the Bazaar repo? :) Can you do a proper branch and merge proposal for this change? Please create a bug too. It just helps us track things much better. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Mon Sep 14 08:22:26 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 14 Sep 2009 08:22:26 +0200 Subject: [Python-mode] beginning-of-defun-function.patch In-Reply-To: <94EA68FA-47EE-46E7-AF69-BBFE41441F03@python.org> References: <4AACC988.4050705@online.de> <94EA68FA-47EE-46E7-AF69-BBFE41441F03@python.org> Message-ID: <4AADE122.6070905@online.de> Barry Warsaw wrote: > On Sep 13, 2009, at 6:29 AM, Andreas Roehler wrote: > >> as mentioned, several modes like C++ or python-mode >> need a more sophisticated determination of beginning- >> or end-of-defun than a regexp may provide. >> >> A additional function-call will be possible with patch >> attached. It allows use of `M-x end-of-defun' in >> python-mode for example. >> >> Should no one object, I'll try to check it in into >> the mercurial repo. > > I think you meant the Bazaar repo? :) > Not this time. :) It's a patch agains XEmacs lisp.el, providing a call of end-, resp. beginning-of-defun-function from beginning-of-defun/end-of-defun. Its a feature available in GNU Emacs, but not in XE. (Was buggy in GNU last time btw.) > Can you do a proper branch and merge proposal for this change? Please > create a bug too. It just helps us track things much better. Will keep that in mind. Andreas > > -Barry > From barry at python.org Mon Sep 14 12:18:55 2009 From: barry at python.org (Barry Warsaw) Date: Mon, 14 Sep 2009 06:18:55 -0400 Subject: [Python-mode] beginning-of-defun-function.patch In-Reply-To: <4AADE122.6070905@online.de> References: <4AACC988.4050705@online.de> <94EA68FA-47EE-46E7-AF69-BBFE41441F03@python.org> <4AADE122.6070905@online.de> Message-ID: On Sep 14, 2009, at 2:22 AM, Andreas Roehler wrote: > Not this time. :) Sorry. Note to self: first sleep, /then/ reply. -B -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Tue Sep 15 15:52:18 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 15 Sep 2009 15:52:18 +0200 Subject: [Python-mode] [Merge] lp:~freiksenet/python-mode/hide-show-support into lp:python-mode In-Reply-To: <20090915114018.27719.54905.launchpad@loganberry.canonical.com> References: <20090915114018.27719.54905.launchpad@loganberry.canonical.com> Message-ID: <4AAF9C12.7080808@online.de> Mikhail Novikov wrote: > Mikhail Novikov has proposed merging lp:~freiksenet/python-mode/hide-show-support into lp:python-mode. > > Requested reviews: > python-mode.el developers (python-mode-devs) > > I have added possibility to modify which keywords' blocks you want to be hideable and if you want dostrings to be hideable. I also removed extra text, as I was advised too. > Hi Mikail, thanks a lot! Hi Barry, tested it with XEmacs 21.5 (beta28) "fuki" (+CVS-20070806) [Lucid] (i386-suse-linux, Mule) of Thu Jan 24 2008 on molitor Emacs -q, and GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2009-07-25 Works for me. May you check it in? Thanks Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ From forgetta at gmail.com Wed Sep 16 16:51:51 2009 From: forgetta at gmail.com (Vincenzo Forgetta) Date: Wed, 16 Sep 2009 10:51:51 -0400 Subject: [Python-mode] PDF reference card for python-mode Message-ID: <4AB0FB87.50107@gmail.com> Hi all, I've am currently attempting to "master" Emacs and python-mode. I've noticed that http://refcards.com has a nice Emacs card, but not a python-mode reference card. Apart from websites that list keyboard shortcuts for python mode (e.g. http://python.about.com/b/2007/09/24/emacs-tips-for-python-programmers.htm), is there a PDF version of the keyboard shortcuts for python-mode? If not, I will take the liberty of making one, but decided to ask before in order to avoid needlessly duplication of effort ;) Thanks in advance for the replies. Vince From andreas.roehler at online.de Fri Sep 25 11:12:12 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 25 Sep 2009 11:12:12 +0200 Subject: [Python-mode] hs-minor-mode, add-to-list Message-ID: <4ABC896C.6080303@online.de> Hi Mikhail, intend to propose your patch for XEmacs. Having a look at it at again, see you removed - (unless (assoc 'python-mode hs-special-modes-alist) remains (setq hs-special-modes-alist (cons (list Think it was a useful check, as loading python-mode at several occasions will cons it again and again. The best form to avoid that is not `(unless (assoc' IMO, but the use of add-to-list instead of cons. If agreed, may you change that so far? Thanks Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ From barry at python.org Fri Sep 25 22:18:58 2009 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Sep 2009 16:18:58 -0400 Subject: [Python-mode] PDF reference card for python-mode In-Reply-To: <4AB0FB87.50107@gmail.com> References: <4AB0FB87.50107@gmail.com> Message-ID: <225BBB7B-344E-4366-851E-30F3D2C885E2@python.org> On Sep 16, 2009, at 10:51 AM, Vincenzo Forgetta wrote: > I've am currently attempting to "master" Emacs and python-mode. I've > noticed that http://refcards.com has a nice Emacs card, but not a > python-mode reference card. Apart from websites that list keyboard > shortcuts for python mode (e.g. http://python.about.com/b/2007/09/24/emacs-tips-for-python-programmers.htm) > , is there a PDF version of the keyboard shortcuts for python-mode? > If not, I will take the liberty of making one, but decided to ask > before in order to avoid needlessly duplication of effort ;) Not that I know of. Contributions are welcome! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at online.de Sun Sep 27 10:10:21 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 27 Sep 2009 10:10:21 +0200 Subject: [Python-mode] simplifying beginning-of-defun In-Reply-To: References: <4ABE54F9.7090107@online.de> Message-ID: <4ABF1DED.6050906@online.de> Stefan Monnier wrote: >> simplifying forms as below should ease maintenance and speed up execution. > > To what extent does it preserve compatibility? Don't see anything incompatible for the moment. OTOH it will take some feasible bugs from progmodes. It underlines a paradigm change, which was introduced with var `beginning-of-defun-function' already. These facility departs from all-at-once solutions, which have been likely creating a bug in the back, while solving one in the forehead. With `beginning-of-defun-function', `end-of-defun-function' python-mode for example https://launchpad.net/python-mode may set its own function and M-x beginning-of-defun then will work still - which is not the case presently and my point of depart here. > > Apparently it makes beginning-of-defun-raw ignore > beginning-of-defun-function, and it calls end-of-defun-function with one > argument contrary to the current situation where it's called without > any argument. An argument is useful here: as a repeat or specifier. So your code wouldn't be acceptable as is since it would > likely break several packages. > > Which performance problem is it trying to solve? All which useless code execution causes. Regard the lines of code saved that way to have an approximation. > > The main difference I see between your beginning-of-defun and Emacs's > one is that yours doesn't try to handle the case where > beginning-of-defun-function, defun-prompt-regexp, and > open-paren-in-column-0-is-defun-start and all nil. This case was added > fairly recently (Emacs-22, IIRC) after a long discussion. Gladly to see, discussions here seldom turn out that badly. :) open-paren-in-column-0-is-defun-start is purely redundant, as the regexp may specify that - and indeed does already(?) its just that what I read with "^\\s(" I do not like > this extra case at all, actually, but if you're trying to get rid of it, > please make it a separate thread. > > In other words, if you send new code just to simplify the existing one, > than make sure the incompatibilities Mentioned code of a end-of-defun-function in lisp.el is a bug. Suggest to cancel it. Let the -raw functions do everything needed for emacs-lisp. Funcalls of beginning-of-defun-function, end-of-defun-function should be reserved for progmodes. BTW if mode-specific, probably it should be introduced as a local var from the very beginning? are clearly understood and > "minor". Otherwise, better focus on the proposal for the change in > behavior, and then accompany that with a patch showing how you suggest > to implement this change. > > > Stefan > Found a bug still in end-of-defun. Changed code below: ;; GNU's lisp.el ;; unhappily sets this var globally, ignoring its use for progmodes (when (featurep 'emacs) (setq end-of-defun-function nil)) (setq defun-searchform '(if defun-prompt-regexp (concat "^\\s(\\|" "\\(" defun-prompt-regexp "\\)\\s(") "^\\s(")) (defun beginning-of-defun (&optional arg) "Move backward to the beginning of a functions definition. " (interactive "P") (or arg (setq arg 1)) (if beginning-of-defun-function (funcall beginning-of-defun-function arg) (beginning-of-defun-raw arg))) (defun beginning-of-defun-raw (&optional arg) "Called if progmodes didn't set beginning-of-defun-function. " (when (re-search-backward (eval defun-searchform) nil 'move (or arg 1)) (goto-char (match-beginning 0)))) (defun end-of-defun (&optional arg) "Move backward to the end of a function. " (interactive "P") (or arg (setq arg 1)) (if end-of-defun-function (funcall end-of-defun-function arg) (end-of-defun-raw arg))) (defun end-of-defun-raw (&optional arg) "Called if progmodes didn't set end-of-defun-function. " (skip-chars-forward " \t\r\n\f") (when (looking-at (eval defun-searchform)) (forward-char -1)) (when (re-search-forward (eval defun-searchform) nil t arg) (goto-char (match-beginning 0)) (forward-sexp 1))) ;;;;;;;;;;; From andreas.roehler at online.de Sun Sep 27 18:07:31 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 27 Sep 2009 18:07:31 +0200 Subject: [Python-mode] simplifying beginning-of-defun (2) Message-ID: <4ABF8DC3.9030504@online.de> Below again the code, as end-of-defun-raw had a bug last times ;; GNU's lisp.el ;; unhappily sets this var globally, ignoring its use for progmodes (when (featurep 'emacs) (setq end-of-defun-function nil)) (setq defun-searchform '(if defun-prompt-regexp (concat "^\\s(\\|" "\\(" defun-prompt-regexp "\\)\\s(") "^\\s(")) (defun beginning-of-defun (&optional arg) "Move backward to the beginning of a functions definition. " (interactive "P") (or arg (setq arg 1)) (if beginning-of-defun-function (funcall beginning-of-defun-function arg) (beginning-of-defun-raw arg))) (defun beginning-of-defun-raw (&optional arg) "Called if progmodes didn't set beginning-of-defun-function. " (when (re-search-backward (eval defun-searchform) nil 'move (or arg 1)) (goto-char (match-beginning 0)))) (defun end-of-defun (&optional arg) "Move backward to the end of a function. " (interactive "P") (or arg (setq arg 1)) (if end-of-defun-function (funcall end-of-defun-function arg) (end-of-defun-raw arg))) (defun end-of-defun-raw (&optional arg) "Called if progmodes didn't set end-of-defun-function. " (skip-chars-forward " \t\r\n\f") (unless (looking-at (eval defun-searchform)) (beginning-of-defun 1)) (when (re-search-forward (eval defun-searchform) nil t arg) (goto-char (match-beginning 0)) (forward-sexp 1))) From monnier at iro.umontreal.ca Sun Sep 27 20:40:56 2009 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Sun, 27 Sep 2009 14:40:56 -0400 Subject: [Python-mode] simplifying beginning-of-defun In-Reply-To: <4ABF1DED.6050906@online.de> (Andreas Roehler's message of "Sun, 27 Sep 2009 10:10:21 +0200") References: <4ABE54F9.7090107@online.de> <4ABF1DED.6050906@online.de> Message-ID: >>> simplifying forms as below should ease maintenance and speed up execution. >> To what extent does it preserve compatibility? > Don't see anything incompatible for the moment. I actually mentionned obvious incompatibilities in the email to which you reply. > With `beginning-of-defun-function', > `end-of-defun-function' python-mode for example > https://launchpad.net/python-mode > may set its own function and M-x beginning-of-defun then > will work still - which is not the case presently and my point of > depart here. I do not understand the above paragraph. >> Apparently it makes beginning-of-defun-raw ignore >> beginning-of-defun-function, and it calls end-of-defun-function with one >> argument contrary to the current situation where it's called without >> any argument. > An argument is useful here: as a repeat or specifier. I was pointing out incompatibilities. Also the current way end-of-defun-function is defined, it does not need a repeat because it only jumps from the beginning of a defun to its end (i.e. it doesn't do the same as end-of-defun). >> Which performance problem is it trying to solve? > All which useless code execution causes. > Regard the lines of code saved that way to have an approximation. This is much too general: OT1H it's not true (larger code is not necessarily slower), OTOH (and more importantly) it doesn't help me understand which specific performance problem this is aiming to address. > open-paren-in-column-0-is-defun-start is purely redundant, as the > regexp may specify that - and indeed does already(?) its just that > what I read with "^\\s(" Again, please move this discussion to a separate thread. > Mentioned code of a end-of-defun-function in lisp.el is a bug. > Suggest to cancel it. I do not know which code nor which bug you talking about. Your code? Emacs's code? > Let the -raw functions do everything needed for emacs-lisp. AFAICT, that's already the way it's designed (that's why it doesn't set the mark, for example). > Funcalls of beginning-of-defun-function, end-of-defun-function should > be reserved for progmodes. I have no idea what you mean by "progmodes". > BTW if mode-specific, probably it should be introduced as a local var > from the very beginning? I'm not sure I understand. Are you suggesting we (make-varible-buffer-local 'beginning-of-defun-function)? Stefan From skip at pobox.com Mon Sep 28 16:49:39 2009 From: skip at pobox.com (skip at pobox.com) Date: Mon, 28 Sep 2009 09:49:39 -0500 Subject: [Python-mode] Pymacs on GitHub (fwd) Message-ID: <19136.52483.807816.388352@montanaro.dyndns.org> Thought python-mode folks might find this announcement at least peripherally interesting since it involves Python/Emacs integration. Skip -------------- next part -------------- An embedded message was scrubbed... From: =?UTF-8?B?RnJhbsOnb2lzIFBpbmFyZA==?= Subject: Pymacs on GitHub Date: Mon, 28 Sep 2009 08:07:59 -0400 Size: 9360 URL: From andreas.roehler at online.de Mon Sep 28 21:57:18 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 28 Sep 2009 21:57:18 +0200 Subject: [Python-mode] hs-minor-mode within python-mode Message-ID: <4AC1151E.3030101@online.de> Hi, Mikhail Novikov delivered this patch at https://code.launchpad.net/~freiksenet/python-mode/hide-show-support It enables hide-show mode --hs-minor-mode-- within python-mode. Consider to check it in. Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ -------------- next part -------------- A non-text attachment was scrubbed... Name: hs.patch Type: text/x-patch Size: 846 bytes Desc: not available URL: From andreas.roehler at easy-emacs.de Tue Sep 29 12:39:32 2009 From: andreas.roehler at easy-emacs.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 29 Sep 2009 12:39:32 +0200 Subject: [Python-mode] hide-show support enabled with python-mode.el Message-ID: <4AC1E3E4.5010004@easy-emacs.de> Thanks for contribution! Andreas -------------- next part -------------- An embedded message was scrubbed... From: xemacs-cvs at xemacs.org Subject: CVS update by aroehler packages/xemacs-packages/python-modes ... Date: 29 Sep 2009 10:18:50 -0000 Size: 6103 URL: From andreas.roehler at online.de Tue Sep 29 15:18:44 2009 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 29 Sep 2009 15:18:44 +0200 Subject: [Python-mode] Pymacs on GitHub (fwd) In-Reply-To: <19136.52483.807816.388352@montanaro.dyndns.org> References: <19136.52483.807816.388352@montanaro.dyndns.org> Message-ID: <4AC20934.9000806@online.de> Hi Skip, thats interesting indeed. Setting up an appropriate state-of-the-art (X)Emacs python-environement is an issue requested again and again by users but not delivered until yet. What about to include these and some other useful stuff into XEmacs python-modes? Then provide an installer, to that Python-Folks must not learn Emacs-Lisp first? Shouldn't the XEmacs packages system deliver the needed utils for such a task? Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ skip at pobox.com wrote: > Thought python-mode folks might find this announcement at least peripherally > interesting since it involves Python/Emacs integration. > > Skip > > > > ------------------------------------------------------------------------ > > Subject: > Pymacs on GitHub > From: > Fran?ois Pinard > Date: > Mon, 28 Sep 2009 08:07:59 -0400 > To: > Pymacs people > > To: > Pymacs people > ... > Hi, people. > > This quick hello to say I pushed the Pymacs repository to GitHub. See > http://github.com/pinard/Pymacs > > I would like to experiment with these facilities for a while. There is > an issue tracker and a wiki, and I wonder if we should use them. If > not, better deactivate their tabs early, so people do not get tempted to > rely on them. > > The advantages of such maintainer toys are well known, there is > presumably no need to repeat them. But I have a few cons, that I'd like > to explicit a bit here, seeking for opinions or advice. > > All issues and wiki pages should ideally be bulk-copyable elsewhere, > would the inclination arise. I would not like feeling tied to GitHub, > the same I once felt tied to Sourceforge. Git gives us the freedom of > having usable clones of Pymacs sources outside GitHub, and the GitHub > copy is just a clone among others. I would ideally seek the same > freedom for other services. > > Hopefully, issues and wiki pages keep history. Another point is > protection, if any, against spam. I had a Wiki, not so long ago, that I > ended up deactivating, as I find neither pleasure nor time, really, > playing games with defacers. > > If the issue is attractive enough (it surely looks simple), I might be > tempted to upload a few pending issues to it, and I wonder if and how I > should mask email addresses of submitters, or otherwise, and how to > establish some kind of links so I could retrieve the original > information if needed. My intuition tells me it works more nicely for > submitters already having a GitHub account, but I do not know yet. I > have a strong point against issue trackers in that maintainers should > never force them upon users, but this implies that maintainers could be > able to easily manage issues coming from other means ? email being the > most common. > > GitHub wiki, well, that's yet another markup language to learn. It's a > bit sad each wiki has its own. Also, I much enjoy the ease by which > Tomboy allows me to maintain a lot of notes, a few of them for Pymacs. > It would be fun for me to have some form of inter-operability between > Wiki pages and Tomboy notes ? I wonder how easy it would be for me to > organize. > > A final point would be to document the GitHub facilities we choose to > retain for use in the current Pymacs sites, and cross-link everything > appropriately, so the whole stays nice, usable and elegant enough. > From skip at pobox.com Tue Sep 29 19:29:28 2009 From: skip at pobox.com (skip at pobox.com) Date: Tue, 29 Sep 2009 12:29:28 -0500 Subject: [Python-mode] Pymacs on GitHub (fwd) In-Reply-To: <4AC20934.9000806@online.de> References: <19136.52483.807816.388352@montanaro.dyndns.org> <4AC20934.9000806@online.de> Message-ID: <19138.17400.797052.532099@montanaro.dyndns.org> Andreas> What about to include these and some other useful stuff into Andreas> XEmacs python-modes? What about rewriting python-mode using Pymacs? Sorry, I don't know how to answer your other questions. Skip From barry at python.org Tue Sep 29 20:27:54 2009 From: barry at python.org (Barry Warsaw) Date: Tue, 29 Sep 2009 14:27:54 -0400 Subject: [Python-mode] Pymacs on GitHub (fwd) In-Reply-To: <19138.17400.797052.532099@montanaro.dyndns.org> References: <19136.52483.807816.388352@montanaro.dyndns.org> <4AC20934.9000806@online.de> <19138.17400.797052.532099@montanaro.dyndns.org> Message-ID: I'm not a fan of git, especially when there are two viable Python- based DVCS's (and I'm biased about which one of those I prefer of course :). On Sep 29, 2009, at 1:29 PM, skip at pobox.com wrote: > > Andreas> What about to include these and some other useful stuff > into > Andreas> XEmacs python-modes? > > What about rewriting python-mode using Pymacs? I would not be in favor of that. While I think Pymacs is very cool stuff, I view python-mode.el as lower-level, and it should remain pure elisp, at least to handle the basics of editing Python code. It would be interesting to explore add-ons and extensions though that take advantage of Pymacs for more advanced, IDE-like stuff. Let's keep python-mode.el itself simple though. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 832 bytes Desc: This is a digitally signed message part URL: From andreas.roehler at easy-emacs.de Wed Sep 30 20:25:53 2009 From: andreas.roehler at easy-emacs.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Wed, 30 Sep 2009 20:25:53 +0200 Subject: [Python-mode] Emacs block indentation In-Reply-To: <25676078.post@talk.nabble.com> References: <25676078.post@talk.nabble.com> Message-ID: <4AC3A2B1.9030806@easy-emacs.de> 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/