From andreas.roehler at online.de Wed Feb 1 07:18:22 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Wed, 01 Feb 2012 07:18:22 +0100 Subject: [Python-mode] py-ask-about-save In-Reply-To: <87wr87d2gg.fsf@iro.umontreal.ca> References: <4F283812.9040700@online.de> <87wr87d2gg.fsf@iro.umontreal.ca> Message-ID: <4F28D92E.8070607@online.de> Am 31.01.2012 21:47, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> (defcustom py-ask-about-save t >> "If not nil, ask about which buffers to save before executing some code. >> Otherwise, all modified buffers are saved without asking." > >> Will change the implementation into > >> "If not nil, ask about which buffers to save before executing some code. >> Otherwise do nothing." > >> Opinions? > > Hi, Andreas, and gang! > > I guess this is inspired from compilation-ask-about-save. It is easier > to remember when alike variables have alike behaviour. > > Some Emacs variables have nil, t and 'ask for a value; you surely have > seen some of them, I do not have an example handy. The behaviour could > be controlled by such a 3-valued variable, yet then, the variable name > should be changed to not be misleading. > > Fran?ois > Thanks, Fran?ois. Good idea, will look for that. Andreas From lpeng564 at gmail.com Wed Feb 1 12:37:21 2012 From: lpeng564 at gmail.com (lpeng564 at gmail.com) Date: Wed, 1 Feb 2012 19:37:21 +0800 Subject: [Python-mode] Python-mode Digest, Vol 92, Issue 1 In-Reply-To: References: Message-ID: <89E77159-9DC8-4627-B93C-71710A016663@gmail.com> root On Feb 1, 2012, at 7:00 PM, python-mode-request at python.org wrote: > py-ask-about-save (Andreas R?hler) > 2. Re: py-ask-about-save ( Fran?ois Pinard) > 3. Re: py-ask-about-save (Andreas R?hler) From lpeng564 at gmail.com Wed Feb 1 12:37:28 2012 From: lpeng564 at gmail.com (lpeng564 at gmail.com) Date: Wed, 1 Feb 2012 19:37:28 +0800 Subject: [Python-mode] Python-mode Digest, Vol 92, Issue 1 In-Reply-To: References: Message-ID: <0D32F9AA-E2A5-4351-A65D-5AC1A79294C2@gmail.com> py-ask-about-save (Andreas R?hler) 2. Re: py-ask-about-save ( Fran?ois Pinard) 3. Re: py-ask-about-save (Andreas R?hler) root On Feb 1, 2012, at 7:00 PM, python-mode-request at python.org wrote: > Send Python-mode mailing list submissions to > python-mode at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-mode > or, via email, send a message with subject or body 'help' to > python-mode-request at python.org > > You can reach the person managing the list at > python-mode-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-mode digest..." > > > Today's Topics: > > 1. py-ask-about-save (Andreas R?hler) > 2. Re: py-ask-about-save ( Fran?ois Pinard) > 3. Re: py-ask-about-save (Andreas R?hler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 31 Jan 2012 19:50:58 +0100 > From: Andreas R?hler > To: python-mode at python.org > Subject: [Python-mode] py-ask-about-save > Message-ID: <4F283812.9040700 at online.de> > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > Hi, > > exists a boolean variable > > (defcustom py-ask-about-save t > "If not nil, ask about which buffers to save before executing some code. > Otherwise, all modified buffers are saved without asking." > > ;;;;;;;;;; > > this rather nags me. Saving all buffer unconditional is probably > terrible, OTOH always get questioned by `t' > > Will change the implementation into > > "If not nil, ask about which buffers to save before executing some code. > Otherwise do nothing." > > Opinions? > > Cheers, > > Andreas > > > ------------------------------ > > Message: 2 > Date: Tue, 31 Jan 2012 15:47:11 -0500 > From: pinard at iro.umontreal.ca ( Fran?ois Pinard) > To: Andreas R?hler > Cc: python-mode at python.org > Subject: Re: [Python-mode] py-ask-about-save > Message-ID: <87wr87d2gg.fsf at iro.umontreal.ca> > Content-Type: text/plain; charset=utf-8 > > Andreas R?hler writes: > >> (defcustom py-ask-about-save t >> "If not nil, ask about which buffers to save before executing some code. >> Otherwise, all modified buffers are saved without asking." > >> Will change the implementation into > >> "If not nil, ask about which buffers to save before executing some code. >> Otherwise do nothing." > >> Opinions? > > Hi, Andreas, and gang! > > I guess this is inspired from compilation-ask-about-save. It is easier > to remember when alike variables have alike behaviour. > > Some Emacs variables have nil, t and 'ask for a value; you surely have > seen some of them, I do not have an example handy. The behaviour could > be controlled by such a 3-valued variable, yet then, the variable name > should be changed to not be misleading. > > Fran?ois > > > ------------------------------ > > Message: 3 > Date: Wed, 01 Feb 2012 07:18:22 +0100 > From: Andreas R?hler > To: Fran?ois Pinard > Cc: python-mode at python.org > Subject: Re: [Python-mode] py-ask-about-save > Message-ID: <4F28D92E.8070607 at online.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 31.01.2012 21:47, schrieb Fran?ois Pinard: >> Andreas R?hler writes: >> >>> (defcustom py-ask-about-save t >>> "If not nil, ask about which buffers to save before executing some code. >>> Otherwise, all modified buffers are saved without asking." >> >>> Will change the implementation into >> >>> "If not nil, ask about which buffers to save before executing some code. >>> Otherwise do nothing." >> >>> Opinions? >> >> Hi, Andreas, and gang! >> >> I guess this is inspired from compilation-ask-about-save. It is easier >> to remember when alike variables have alike behaviour. >> >> Some Emacs variables have nil, t and 'ask for a value; you surely have >> seen some of them, I do not have an example handy. The behaviour could >> be controlled by such a 3-valued variable, yet then, the variable name >> should be changed to not be misleading. >> >> Fran?ois >> > > Thanks, Fran?ois. Good idea, will look for that. > > Andreas > > > ------------------------------ > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > > > End of Python-mode Digest, Vol 92, Issue 1 > ****************************************** From pinard at iro.umontreal.ca Wed Feb 1 14:50:02 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Wed, 01 Feb 2012 08:50:02 -0500 Subject: [Python-mode] Python-mode Digest, Vol 92, Issue 1 In-Reply-To: <0D32F9AA-E2A5-4351-A65D-5AC1A79294C2@gmail.com> (lpeng's message of "Wed, 1 Feb 2012 19:37:28 +0800") References: <0D32F9AA-E2A5-4351-A65D-5AC1A79294C2@gmail.com> Message-ID: <87vcnqbr3p.fsf@iro.umontreal.ca> "lpeng564 at gmail.com" writes: > py-ask-about-save (Andreas R?hler) > 2. Re: py-ask-about-save ( Fran?ois Pinard) > 3. Re: py-ask-about-save (Andreas R?hler) Hi, python-mode people. Are these digests, sent to the python-mode mailing list, any useful? They repeat messages already circulated. Could they be stopped? Fran?ois From lpeng564 at gmail.com Fri Feb 3 13:51:45 2012 From: lpeng564 at gmail.com (lpeng564 at gmail.com) Date: Fri, 3 Feb 2012 20:51:45 +0800 Subject: [Python-mode] Python-mode Digest, Vol 92, Issue 2 In-Reply-To: References: Message-ID: <96DB3D15-C370-41BC-BE06-26EF8D9E37FF@gmail.com> root ? Feb 2, 2012?7:00 PM?python-mode-request at python.org ??? > Send Python-mode mailing list submissions to > python-mode at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-mode > or, via email, send a message with subject or body 'help' to > python-mode-request at python.org > > You can reach the person managing the list at > python-mode-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-mode digest..." > > > Today's Topics: > > 1. Re: Python-mode Digest, Vol 92, Issue 1 (lpeng564 at gmail.com) > 2. Re: Python-mode Digest, Vol 92, Issue 1 (lpeng564 at gmail.com) > 3. Re: Python-mode Digest, Vol 92, Issue 1 ( Fran?ois Pinard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 1 Feb 2012 19:37:21 +0800 > From: "lpeng564 at gmail.com" > To: "python-mode at python.org" > Subject: Re: [Python-mode] Python-mode Digest, Vol 92, Issue 1 > Message-ID: <89E77159-9DC8-4627-B93C-71710A016663 at gmail.com> > Content-Type: text/plain; charset=us-ascii > > > > root > > On Feb 1, 2012, at 7:00 PM, python-mode-request at python.org wrote: > >> py-ask-about-save (Andreas R?hler) >> 2. Re: py-ask-about-save ( Fran?ois Pinard) >> 3. Re: py-ask-about-save (Andreas R?hler) > > > ------------------------------ > > Message: 2 > Date: Wed, 1 Feb 2012 19:37:28 +0800 > From: "lpeng564 at gmail.com" > To: "python-mode at python.org" > Subject: Re: [Python-mode] Python-mode Digest, Vol 92, Issue 1 > Message-ID: <0D32F9AA-E2A5-4351-A65D-5AC1A79294C2 at gmail.com> > Content-Type: text/plain; charset=us-ascii > > py-ask-about-save (Andreas R?hler) > 2. Re: py-ask-about-save ( Fran?ois Pinard) > 3. Re: py-ask-about-save (Andreas R?hler) > > root > > On Feb 1, 2012, at 7:00 PM, python-mode-request at python.org wrote: > >> Send Python-mode mailing list submissions to >> python-mode at python.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.python.org/mailman/listinfo/python-mode >> or, via email, send a message with subject or body 'help' to >> python-mode-request at python.org >> >> You can reach the person managing the list at >> python-mode-owner at python.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Python-mode digest..." >> >> >> Today's Topics: >> >> 1. py-ask-about-save (Andreas R?hler) >> 2. Re: py-ask-about-save ( Fran?ois Pinard) >> 3. Re: py-ask-about-save (Andreas R?hler) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 31 Jan 2012 19:50:58 +0100 >> From: Andreas R?hler >> To: python-mode at python.org >> Subject: [Python-mode] py-ask-about-save >> Message-ID: <4F283812.9040700 at online.de> >> Content-Type: text/plain; charset=ISO-8859-15; format=flowed >> >> Hi, >> >> exists a boolean variable >> >> (defcustom py-ask-about-save t >> "If not nil, ask about which buffers to save before executing some code. >> Otherwise, all modified buffers are saved without asking." >> >> ;;;;;;;;;; >> >> this rather nags me. Saving all buffer unconditional is probably >> terrible, OTOH always get questioned by `t' >> >> Will change the implementation into >> >> "If not nil, ask about which buffers to save before executing some code. >> Otherwise do nothing." >> >> Opinions? >> >> Cheers, >> >> Andreas >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 31 Jan 2012 15:47:11 -0500 >> From: pinard at iro.umontreal.ca ( Fran?ois Pinard) >> To: Andreas R?hler >> Cc: python-mode at python.org >> Subject: Re: [Python-mode] py-ask-about-save >> Message-ID: <87wr87d2gg.fsf at iro.umontreal.ca> >> Content-Type: text/plain; charset=utf-8 >> >> Andreas R?hler writes: >> >>> (defcustom py-ask-about-save t >>> "If not nil, ask about which buffers to save before executing some code. >>> Otherwise, all modified buffers are saved without asking." >> >>> Will change the implementation into >> >>> "If not nil, ask about which buffers to save before executing some code. >>> Otherwise do nothing." >> >>> Opinions? >> >> Hi, Andreas, and gang! >> >> I guess this is inspired from compilation-ask-about-save. It is easier >> to remember when alike variables have alike behaviour. >> >> Some Emacs variables have nil, t and 'ask for a value; you surely have >> seen some of them, I do not have an example handy. The behaviour could >> be controlled by such a 3-valued variable, yet then, the variable name >> should be changed to not be misleading. >> >> Fran?ois >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 01 Feb 2012 07:18:22 +0100 >> From: Andreas R?hler >> To: Fran?ois Pinard >> Cc: python-mode at python.org >> Subject: Re: [Python-mode] py-ask-about-save >> Message-ID: <4F28D92E.8070607 at online.de> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Am 31.01.2012 21:47, schrieb Fran?ois Pinard: >>> Andreas R?hler writes: >>> >>>> (defcustom py-ask-about-save t >>>> "If not nil, ask about which buffers to save before executing some code. >>>> Otherwise, all modified buffers are saved without asking." >>> >>>> Will change the implementation into >>> >>>> "If not nil, ask about which buffers to save before executing some code. >>>> Otherwise do nothing." >>> >>>> Opinions? >>> >>> Hi, Andreas, and gang! >>> >>> I guess this is inspired from compilation-ask-about-save. It is easier >>> to remember when alike variables have alike behaviour. >>> >>> Some Emacs variables have nil, t and 'ask for a value; you surely have >>> seen some of them, I do not have an example handy. The behaviour could >>> be controlled by such a 3-valued variable, yet then, the variable name >>> should be changed to not be misleading. >>> >>> Fran?ois >>> >> >> Thanks, Fran?ois. Good idea, will look for that. >> >> Andreas >> >> >> ------------------------------ >> >> _______________________________________________ >> Python-mode mailing list >> Python-mode at python.org >> http://mail.python.org/mailman/listinfo/python-mode >> >> >> End of Python-mode Digest, Vol 92, Issue 1 >> ****************************************** > > > ------------------------------ > > Message: 3 > Date: Wed, 01 Feb 2012 08:50:02 -0500 > From: pinard at iro.umontreal.ca ( Fran?ois Pinard) > To: "python-mode\@python.org" > Subject: Re: [Python-mode] Python-mode Digest, Vol 92, Issue 1 > Message-ID: <87vcnqbr3p.fsf at iro.umontreal.ca> > Content-Type: text/plain; charset=utf-8 > > "lpeng564 at gmail.com" writes: > >> py-ask-about-save (Andreas R?hler) >> 2. Re: py-ask-about-save ( Fran?ois Pinard) >> 3. Re: py-ask-about-save (Andreas R?hler) > > Hi, python-mode people. > > Are these digests, sent to the python-mode mailing list, any useful? > They repeat messages already circulated. Could they be stopped? > > Fran?ois > > > > ------------------------------ > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > > > End of Python-mode Digest, Vol 92, Issue 2 > ****************************************** From beckmann.maik at googlemail.com Sat Feb 4 23:10:15 2012 From: beckmann.maik at googlemail.com (Maik Beckmann) Date: Sat, 4 Feb 2012 23:10:15 +0100 Subject: [Python-mode] ipython setup Message-ID: Hello, By utilizing edebug-defun I figured out how to setup python-mode for ipython, so that completion works in a file buffer (M-TAB) as well as in the ipython comint buffer (TAB): (setq py-complete-function 'ipython-complete py-shell-complete-function 'ipython-complete py-shell-name "ipython" py-which-bufname "IPython") Without setting py-which-bufname to "IPython" emacs told me that no process is connected the buffer. After setting it, it worked as expected. However, I figured this out by using edebug and it might be just a hack. My questions: Am I doing it the way I'm supposed to? Are there docs which talk about how to do it right? Thanks, Maik Beckmann PS: I'm running Archlinux, where /usr/bin/{python,ipython} are both Python 3. The above setting worked when I've temporarily altered these paths to point to python2 and ipython2 respectively. I've changed these back and this is what I'm actually using (setq py-complete-function 'ipython-complete py-shell-complete-function 'ipython-complete py-shell-name "ipython2" py-which-bufname "Ipython2") along with these changes http://paste.pocoo.org/show/545846/ From drouhet at gmail.com Sun Feb 5 00:47:12 2012 From: drouhet at gmail.com (woldri) Date: Sat, 4 Feb 2012 15:47:12 -0800 (PST) Subject: [Python-mode] problem with numpy and kapteyn package Message-ID: <1328399232020-4365764.post@n6.nabble.com> Hello everyone, So let me explain my problem, I had installed scipy-0.10.0 pyfits numpy-1.6.1 kapteyn-2.1%20(2) and when I run my program (written in python) i obtained something very weird like [Valueerror: "c_numpy.pxd", line 76, in _proj (src/_proj.c:3234)] ... in connection with the module "wcs" in "kapteyn"... Thinking the problem came from numpy 1.6.1 and reviewing a forum (from a distance, and diagonally i should admit) i thought it was preferable not to uninstall / remove numpy 1.6.1 before installing another numpy version which seemed to work better to solve the kind of problem i talked about ... i therefore installed numpy 1.3.0 brutally... (by the way I do not know how uninstall numpy 1.6.1 or remove it or downgrade to numpy 1.3 or what , and incidentally I may well not have searched enough and the web but i did not found how to even use numpy 1.3 when you have previously installed numpy 1.6.1 ) and now i get a very bad problem far worse than the previous (that problem, i can quote it extensively because i have it right now on my screen): Traceback (most recent call last): File "example33.py", line 5, in import pyfits File "/usr/local/lib/python2.6/dist-packages/pyfits-2.4.0-py2.6.egg/pyfits/__init__.py", line 17, in from core import * File "/usr/local/lib/python2.6/dist-packages/pyfits-2.4.0-py2.6.egg/pyfits/core.py", line 36, in import numpy as np File "/home/boubou/.local/lib/python2.6/site-packages/numpy/__init__.py", line 128, in from version import git_revision as __git_revision__ ImportError: cannot import name git_revision If anyone would be so kind as to find a way out of this problem , it would be very very very helpful ! -- View this message in context: http://python.6.n6.nabble.com/problem-with-numpy-and-kapteyn-package-tp4365764p4365764.html Sent from the Python - python-mode mailing list archive at Nabble.com. From Tom_Roche at pobox.com Sun Feb 5 01:26:43 2012 From: Tom_Roche at pobox.com (Tom Roche) Date: Sat, 04 Feb 2012 19:26:43 -0500 Subject: [Python-mode] problem with numpy and kapteyn package In-Reply-To: <1328399232020-4365764.post@n6.nabble.com> References: <1328399232020-4365764.post@n6.nabble.com> Message-ID: <87ehuaf7lo.fsf@pobox.com> woldri Sat, 4 Feb 2012 15:47:12 -0800 (PST) > So let me explain my problem, >From your explanation, your problem appears to have nothing to do with python-mode (a part of emacs), which is the topic of this list. Rather, you seem to have a python problem, which is better asked on a more general python help list, e.g., http://mail.python.org/mailman/listinfo/tutor or one of the Enthought (the numpy/scipy vendor) lists http://www.scipy.org/Mailing_Lists > i thought it was preferable not to uninstall / remove numpy 1.6.1 > before installing another numpy version which seemed to work better > to solve the kind of problem i talked about ... i therefore > installed numpy 1.3.0 brutally... (by the way I do not know how > uninstall numpy 1.6.1 or remove it or downgrade to numpy 1.3 or what > , and incidentally I may well not have searched enough and the web > but i did not found how to even use numpy 1.3 when you have > previously installed numpy 1.6.1 ) Note that (IIUC) the state-of-the-art way to support multiple independent python configurations (which involves less brutality :-) is virtualenv, about which you can get help here http://groups.google.com/group/python-virtualenv HTH, Tom Roche From andreas.roehler at online.de Sun Feb 5 21:15:41 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Sun, 05 Feb 2012 21:15:41 +0100 Subject: [Python-mode] ipython setup In-Reply-To: References: Message-ID: <4F2EE36D.3000606@online.de> Am 04.02.2012 23:10, schrieb Maik Beckmann: > Hello, > > By utilizing edebug-defun I figured out how to setup python-mode > for ipython, so that completion works in a file buffer (M-TAB) as > well as in the ipython comint buffer (TAB): > > (setq py-complete-function 'ipython-complete > py-shell-complete-function 'ipython-complete > py-shell-name "ipython" > py-which-bufname "IPython") > > Without setting py-which-bufname to "IPython" emacs told me that > no process is connected the buffer. After setting it, it worked > as expected. However, I figured this out by using edebug and it > might be just a hack. > > My questions: Am I doing it the way I'm supposed to? Are there > docs which talk about how to do it right? Hi, you should not need any customization for IPython. There was a bug, which shold be gone now. Could you try from current trunk again? Made a bug report lp:927136 for this. Let's continue there, should something being left. thanks for your report, Andreas > > > Thanks, > Maik Beckmann > > PS: I'm running Archlinux, where /usr/bin/{python,ipython} are > both Python 3. The above setting worked when I've temporarily > altered these paths to point to python2 and ipython2 > respectively. I've changed these back and this is what I'm > actually using > > (setq py-complete-function 'ipython-complete > py-shell-complete-function 'ipython-complete > py-shell-name "ipython2" > py-which-bufname "Ipython2") > > along with these changes http://paste.pocoo.org/show/545846/ From kroger at pedrokroger.net Tue Feb 7 02:00:54 2012 From: kroger at pedrokroger.net (Pedro Kroger) Date: Mon, 6 Feb 2012 23:00:54 -0200 Subject: [Python-mode] How to execute buffer to iPython? Message-ID: <1B20B5A9-1B03-455D-9CAF-92C2A01B1A28@pedrokroger.net> Hi, How can I execute a buffer (with C-c C-c) to an iPython shell? (that was opened with M-x ipython) I'm using python-mode from the repository (revision 823) and GNU Emacs 24.0.93.1 on a Mac Os. I tried to set python-python-command to "/usr/local/bin/ipython" but it didn't work. I used to be able to do this, so maybe there's something that I'm missing. Thanks, Pedro -- http://pedrokroger.net From andreas.roehler at online.de Tue Feb 7 07:36:30 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 07 Feb 2012 07:36:30 +0100 Subject: [Python-mode] How to execute buffer to iPython? In-Reply-To: <1B20B5A9-1B03-455D-9CAF-92C2A01B1A28@pedrokroger.net> References: <1B20B5A9-1B03-455D-9CAF-92C2A01B1A28@pedrokroger.net> Message-ID: <4F30C66E.5060902@online.de> Am 07.02.2012 02:00, schrieb Pedro Kroger: > Hi, > > How can I execute a buffer (with C-c C-c) to an iPython shell? (that was opened with M-x ipython) Hi, doing M-x ipython first should not be a requireness, whilst in fact it is, as the first time execution might fail - afterwards python-mode opened that shell silently. When ipython is set as py-shell-name and a different shebang doesn't interfere, C-c C-c should work as expected. When checking this, see it has a bug. Will look for a fix, thanks pointing to that, > > I'm using python-mode from the repository (revision 823) and GNU Emacs 24.0.93.1 on a Mac Os. > I tried to set python-python-command to "/usr/local/bin/ipython" but it didn't work. will remove that python-python-command as being redundant with py-shell-name Andreas > > I used to be able to do this, so maybe there's something that I'm missing. > > Thanks, > > Pedro > > -- > http://pedrokroger.net > > > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From andreas.roehler at online.de Wed Feb 8 09:56:23 2012 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Wed, 08 Feb 2012 09:56:23 +0100 Subject: [Python-mode] menu item names Message-ID: <4F3238B7.4000407@online.de> Hi Barry, hi all, being pointed at some irregularity menu items now display, what about to rename it that way: PyIndex PyShell PyTools PyCommands (?) BTW PyShell still should take the virtualenv stuff, when ready Cheers, Andreas From jbauer at rubic.com Wed Feb 8 14:53:20 2012 From: jbauer at rubic.com (Jeff Bauer) Date: Wed, 8 Feb 2012 07:53:20 -0600 Subject: [Python-mode] menu item names In-Reply-To: <4F3238B7.4000407@online.de> References: <4F3238B7.4000407@online.de> Message-ID: <20120208135320.GA17947@rubic.com> On Wed, Feb 08, 2012 at 09:56:23AM +0100, Andreas R?hler wrote: > Hi Barry, hi all, > > being pointed at some irregularity menu items now display, > what about to rename it that way: > > PyIndex > PyShell > PyTools > PyCommands > > (?) > BTW PyShell still should take the virtualenv stuff, when ready +1 Jeff Bauer Rubicon, Inc. From barry at python.org Wed Feb 8 16:07:22 2012 From: barry at python.org (Barry Warsaw) Date: Wed, 8 Feb 2012 10:07:22 -0500 Subject: [Python-mode] menu item names In-Reply-To: <4F3238B7.4000407@online.de> References: <4F3238B7.4000407@online.de> Message-ID: <20120208100722.56ebabbe@resist.wooz.org> On Feb 08, 2012, at 09:56 AM, Andreas R?hler wrote: >being pointed at some irregularity menu items now display, >what about to rename it that way: > >PyIndex >PyShell >PyTools >PyCommands > >(?) >BTW PyShell still should take the virtualenv stuff, when ready What are "menus"? :) Seriously, I have little useful feedback, as I disable all Emacs menus. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From pinard at iro.umontreal.ca Wed Feb 8 16:17:08 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Wed, 08 Feb 2012 10:17:08 -0500 Subject: [Python-mode] menu item names In-Reply-To: <20120208135320.GA17947@rubic.com> (Jeff Bauer's message of "Wed, 8 Feb 2012 07:53:20 -0600") References: <4F3238B7.4000407@online.de> <20120208135320.GA17947@rubic.com> Message-ID: <87ipjhfj7v.fsf@iro.umontreal.ca> Jeff Bauer writes: > On Wed, Feb 08, 2012 at 09:56:23AM +0100, Andreas R?hler wrote: >> PyIndex >> PyShell >> PyTools >> PyCommands > +1 PyCommands is a bit longish visually, and the name does not give a big clue that it gives a menu for the Python mode proper. Could it be something like `Python' or `PyMode' maybe? I'm not fully satisfied, but do not have a better idea. Fran?ois From andreas.roehler at online.de Wed Feb 8 18:46:54 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Wed, 08 Feb 2012 18:46:54 +0100 Subject: [Python-mode] menu item names In-Reply-To: <87ipjhfj7v.fsf@iro.umontreal.ca> References: <4F3238B7.4000407@online.de> <20120208135320.GA17947@rubic.com> <87ipjhfj7v.fsf@iro.umontreal.ca> Message-ID: <4F32B50E.7000204@online.de> Am 08.02.2012 16:17, schrieb Fran?ois Pinard: > Jeff Bauer writes: > >> On Wed, Feb 08, 2012 at 09:56:23AM +0100, Andreas R?hler wrote: > >>> PyIndex >>> PyShell >>> PyTools >>> PyCommands > >> +1 > > PyCommands is a bit longish visually, and the name does not give a big > clue that it gives a menu for the Python mode proper. Could it be > something like `Python' or `PyMode' maybe? I'm not fully satisfied, but > do not have a better idea. > > Fran?ois > what about moving the exec stuff into now PyShell, renaming PyShell PyExec than PyCommands might be renamed PyEdit ? From pinard at iro.umontreal.ca Wed Feb 8 19:36:45 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Wed, 08 Feb 2012 13:36:45 -0500 Subject: [Python-mode] menu item names In-Reply-To: <4F32B50E.7000204@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Wed, 08 Feb 2012 18:46:54 +0100") References: <4F3238B7.4000407@online.de> <20120208135320.GA17947@rubic.com> <87ipjhfj7v.fsf@iro.umontreal.ca> <4F32B50E.7000204@online.de> Message-ID: <87y5sddveq.fsf@iro.umontreal.ca> Andreas R?hler writes: > than PyCommands might be renamed PyEdit PyEdit! Hey, that's the best so far! :-) Fran?ois From andreas.roehler at online.de Thu Feb 9 08:22:23 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Thu, 09 Feb 2012 08:22:23 +0100 Subject: [Python-mode] menu item names In-Reply-To: <20120208100722.56ebabbe@resist.wooz.org> References: <4F3238B7.4000407@online.de> <20120208100722.56ebabbe@resist.wooz.org> Message-ID: <4F33742F.6070709@online.de> Am 08.02.2012 16:07, schrieb Barry Warsaw: > On Feb 08, 2012, at 09:56 AM, Andreas R?hler wrote: > >> being pointed at some irregularity menu items now display, >> what about to rename it that way: >> >> PyIndex >> PyShell >> PyTools >> PyCommands >> >> (?) >> BTW PyShell still should take the virtualenv stuff, when ready > > What are "menus"? :) > > Seriously, I have little useful feedback, as I disable all Emacs menus. > when ready, it should deliver a nice reference also for the experienced user. but wait... :) > Cheers, > -Barry From pinard at iro.umontreal.ca Tue Feb 14 14:29:47 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Tue, 14 Feb 2012 08:29:47 -0500 Subject: [Python-mode] bug with shipped pymacs? In-Reply-To: <87vcrxeu8y.fsf@pobox.com> (Tom Roche's message of "Sun, 09 Oct 2011 17:21:33 -0400") References: <4E913DCB.8080404@online.de> <4E8F3C7C.2040606@online.de> <87y5ww94lq.fsf@pobox.com> <87vcryalon.fsf@pobox.com> <87vcrxeu8y.fsf@pobox.com> Message-ID: <877gzpee5w.fsf@iro.umontreal.ca> Tom Roche writes: > summary: something is wrong with the pymacs I installed with > python-mode=6.0.3, or with my installation or use of it. >> Debugger entered--Lisp error: (error "Pymacs Lisp version is >> @VERSION@, Python is 0.24-beta2") Hi, Tom. The pymacs.el file was likely copied verbatim, out of pymacs.el.in from the Pymacs distribution. The ".in" suffix is a hint that the file needs processing before "becoming" the usable file. The problem may be there! There is a Makefile in the distribution that takes care of these things, and the installation documentation tries to stress that one should either run "make" or at least do the equivalent by other means. I would surely like that python-mode use Pymacs in a more solid way, and just not try to "patch it" in. Don't hesitate to use me, if I can help. If you do not thrown bug trackers at me, I'm quite speakable! :-) Fran?ois P.S. - Who should nevertheless warn you that I may be a bit slow at replying, surely not because of bad will, but as I miss free time. From ribonucleico at gmail.com Tue Feb 14 16:12:40 2012 From: ribonucleico at gmail.com (rosoloum) Date: Tue, 14 Feb 2012 07:12:40 -0800 (PST) Subject: [Python-mode] ipython setup In-Reply-To: <4F2EE36D.3000606@online.de> References: <4F2EE36D.3000606@online.de> Message-ID: <1329232360395-4469146.post@n6.nabble.com> I am also having troubles setting up python-mode to work with ipython. I am using python-mode.el 6.0.4 (latest version, released on 2011-12-30). On the Launchpad site I see the following series and milestones posterior to 6.0.4: 6.0.4, 6.05, 6.1 and 6.1.1 When you said "could you try from the current trunk again?" which version do you mean? -- View this message in context: http://python.6.n6.nabble.com/ipython-setup-tp4365625p4469146.html Sent from the Python - python-mode mailing list archive at Nabble.com. From andreas.roehler at online.de Tue Feb 14 16:46:53 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 14 Feb 2012 16:46:53 +0100 Subject: [Python-mode] ipython setup In-Reply-To: <1329232360395-4469146.post@n6.nabble.com> References: <4F2EE36D.3000606@online.de> <1329232360395-4469146.post@n6.nabble.com> Message-ID: <4F3A81ED.9080409@online.de> Am 14.02.2012 16:12, schrieb rosoloum: > I am also having troubles setting up python-mode to work with ipython. I am > using python-mode.el 6.0.4 (latest version, released on 2011-12-30). > > On the Launchpad site I see the following series and milestones posterior to > 6.0.4: > > 6.0.4, 6.05, 6.1 and 6.1.1 > > When you said "could you try from the current trunk again?" which version do > you mean? > constants versions number of the trunk is rather meaningless - it's just higher than the last released one. With trunk the revision, the check-in stamp is important. get the last revision by bzr branch lp:python-mode From ribonucleico at gmail.com Tue Feb 14 17:01:42 2012 From: ribonucleico at gmail.com (rosoloum) Date: Tue, 14 Feb 2012 08:01:42 -0800 (PST) Subject: [Python-mode] ipython setup In-Reply-To: <4F3A81ED.9080409@online.de> References: <4F2EE36D.3000606@online.de> <1329232360395-4469146.post@n6.nabble.com> <4F3A81ED.9080409@online.de> Message-ID: <1329235302541-4469277.post@n6.nabble.com> Thanks! I just installed the latest version. In your previous post in this thread you said: " .... you should not need any customization for IPython. There was a bug, which shold be gone now. Could you try from current trunk again? ... " However, when I tried M-x ipython but I got "no match" I have the following on my .emacs file: (add-to-list 'load-path "~/.emacs.d/python-mode/") (setq py-install-directory "~/.emacs.d/python-mode/") (require 'python-mode) Is there anything else I need to put in my .emacs file to debug and execute my code on an IPython buffer? Thanks _______________________________________________ Python-mode mailing list Python-mode@ http://mail.python.org/mailman/listinfo/python-mode -- View this message in context: http://python.6.n6.nabble.com/ipython-setup-tp4365625p4469277.html Sent from the Python - python-mode mailing list archive at Nabble.com. From andreas.roehler at online.de Tue Feb 14 17:40:23 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 14 Feb 2012 17:40:23 +0100 Subject: [Python-mode] ipython setup In-Reply-To: <1329235302541-4469277.post@n6.nabble.com> References: <4F2EE36D.3000606@online.de> <1329232360395-4469146.post@n6.nabble.com> <4F3A81ED.9080409@online.de> <1329235302541-4469277.post@n6.nabble.com> Message-ID: <4F3A8E77.2020604@online.de> Am 14.02.2012 17:01, schrieb rosoloum: > Thanks! I just installed the latest version. > > In your previous post in this thread you said: > > " .... you should not need any customization for IPython. There was a bug, > which shold be gone now. Could you try from current trunk again? ... " > > However, when I tried M-x ipython but I got "no match" > Please make an entry at https://bugs.launchpad.net/python-mode start from emacs -q, evaluate these install forms and send the output from M-x report-emacs-bug Thanks, Andreas [ ... ] From andreas.roehler at online.de Tue Feb 14 19:31:56 2012 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 14 Feb 2012 19:31:56 +0100 Subject: [Python-mode] py-shell-switch-buffers-on-execute change Message-ID: <4F3AA89C.1090104@online.de> Hi all, this var sets a default, if its switched to the output buffer. When shells are opened interactively however, think it should ignore that value, switch always instead. Are there cases where after a M-x python it should not be switched to the shell? Unless objections coming in, will do that change. Cheers, Andreas From andrea.crotti.0 at gmail.com Tue Feb 14 22:31:58 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Tue, 14 Feb 2012 21:31:58 +0000 Subject: [Python-mode] huge files Message-ID: <4F3AD2CE.5050903@gmail.com> It looks like it's a common "problem" in the Elisp world, but I was wondering is it normal to have huge source files. python-mode.el is > 10k lines now, which for me causes two problems: - it's hard to even know the various functionalities - it's hard to manage the file I see various things that could be very easily splitted - virtualenv - ipython - pdbtrack (maybe) - defcustom-defvar (or maybe better by topic taking the variables together) and probably more. Since it doesn't do any difference in terms of performance and it's much less intimidating to try to grasp, is there a reason to keep all in one big file? From andreas.roehler at online.de Wed Feb 15 09:34:36 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Wed, 15 Feb 2012 09:34:36 +0100 Subject: [Python-mode] huge files In-Reply-To: <4F3AD2CE.5050903@gmail.com> References: <4F3AD2CE.5050903@gmail.com> Message-ID: <4F3B6E1C.5080307@online.de> Am 14.02.2012 22:31, schrieb Andrea Crotti: > It looks like it's a common "problem" in the Elisp world, but I was > wondering is it normal to have huge source files. > > python-mode.el is > 10k lines now, which for me causes two problems: > - it's hard to even know the various functionalities > - it's hard to manage the file > > I see various things that could be very easily splitted > - virtualenv > - ipython > - pdbtrack (maybe) > - defcustom-defvar (or maybe better by topic taking the variables together) > > and probably more. > Since it doesn't do any difference in terms of performance and it's > much less intimidating to try to grasp, is there a reason to keep all in > one big file? think it's basically historical. People interested in developing/understanding might check out and use the components branch https://code.launchpad.net/~a-roehler/python-mode/components-python-mode I'm doing all my developing and Python editing there. It's sometimes ahead several days, if new features are introduced. But the same tests are run before commits, so a possible loss in stability is mince. BTW in future we could create a declared stable branch of components and make two tarballs for release. CC to Barry for this question. Andreas From andrea.crotti.0 at gmail.com Wed Feb 15 10:52:47 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Wed, 15 Feb 2012 09:52:47 +0000 Subject: [Python-mode] huge files In-Reply-To: <4F3B6E1C.5080307@online.de> References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> Message-ID: <4F3B806F.3010507@gmail.com> On 02/15/2012 08:34 AM, Andreas R?hler wrote: > > think it's basically historical. > > People interested in developing/understanding might check out and use > the components branch > > https://code.launchpad.net/~a-roehler/python-mode/components-python-mode > > I'm doing all my developing and Python editing there. > It's sometimes ahead several days, if new features are introduced. But > the same tests are run before commits, so a possible loss in stability > is mince. > > BTW in future we could create a declared stable branch of components > and make two tarballs for release. > > CC to Barry for this question. > > Andreas Ah i see interesting, so you did already this split.. Well I think that only one file might be easier to deploy, but the average Emacs user should not really have problems in untarring a tar and change the load path, right? And the thing is that if I checkout the bzr repo I would expect that I see the same structure that the devs are actually seeing, otherwise it's also harder to apply patches directly reported from others for example. So a big +1 in a declared stable branch of components :) From barry at python.org Wed Feb 15 13:57:46 2012 From: barry at python.org (Barry Warsaw) Date: Wed, 15 Feb 2012 07:57:46 -0500 Subject: [Python-mode] huge files In-Reply-To: <4F3B6E1C.5080307@online.de> References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> Message-ID: <20120215075746.00946510@resist.wooz.org> On Feb 15, 2012, at 09:34 AM, Andreas R?hler wrote: >think it's basically historical. > >People interested in developing/understanding might check out and use the components branch > >https://code.launchpad.net/~a-roehler/python-mode/components-python-mode > >I'm doing all my developing and Python editing there. >It's sometimes ahead several days, if new features are introduced. But the same tests are run before commits, so a possible loss in stability is mince. > >BTW in future we could create a declared stable branch of components and make two tarballs for release. I've always thought that because python-mode.el is a separate download, it's better to have one big file. This makes it easier for users to add it to their Emacsen, even though it makes it more difficult to maintain, as rightly observed. But maybe we're at the tipping point where that trade-off should go the other way. Good, discoverable, installation documentation would go a long way toward alleviating those concerns. I run python-mode out of the bzr trunk, so I'm probably not a good use case. In a very real sense, this is Andreas's decision now. "He who does the work, decides" and Andreas has for quite a while now assumed primary ownership on the code, by virtue of his great work on the mode. I have no place to stand in the way of his decision on this. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jbauer at rubic.com Wed Feb 15 15:16:43 2012 From: jbauer at rubic.com (Jeff Bauer) Date: Wed, 15 Feb 2012 08:16:43 -0600 Subject: [Python-mode] huge files In-Reply-To: <20120215075746.00946510@resist.wooz.org> References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> <20120215075746.00946510@resist.wooz.org> Message-ID: <20120215141643.GC20869@rubic.com> On Wed, Feb 15, 2012 at 07:57:46AM -0500, Barry Warsaw wrote: > On Feb 15, 2012, at 09:34 AM, Andreas R?hler wrote: > > >think it's basically historical. > > > >People interested in developing/understanding might check out > >and use the components branch > > > >https://code.launchpad.net/~a-roehler/python-mode/components-python-mode > > > >I'm doing all my developing and Python editing there. It's > >sometimes ahead several days, if new features are > >introduced. But the same tests are run before commits, so a > >possible loss in stability is mince. > > > >BTW in future we could create a declared stable branch of > >components and make two tarballs for release. > > I've always thought that because python-mode.el is a separate > download, it's better to have one big file. This makes it > easier for users to add it to their Emacsen, even though it > makes it more difficult to maintain, as rightly observed. > > But maybe we're at the tipping point where that trade-off should > go the other way. Good, discoverable, installation > documentation would go a long way toward alleviating those > concerns. I run python-mode out of the bzr trunk, so I'm > probably not a good use case. > > In a very real sense, this is Andreas's decision now. "He who > does the work, decides" and Andreas has for quite a while now > assumed primary ownership on the code, by virtue of his great > work on the mode. I have no place to stand in the way of his > decision on this. Extending what Barry said ... python-mode.el already has a hurdle to overcome, as it's not distributed with emacs. I think a single file makes it easier for non-experts (I'm in this category) to drop in .emacs.d and run. http://marmalade-repo.org/about However, as the Marmalade server (hopefully) becomes a standard method for distributing 3rd party emacs packages, then multi-file python-mode will be a non-issue. Perhaps we might see some convergence in this direction? Agreed that the decision is Andreas's, and I thank him for his efforts. Jeff Bauer Rubicon, Inc. From pinard at iro.umontreal.ca Wed Feb 15 16:08:22 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Wed, 15 Feb 2012 10:08:22 -0500 Subject: [Python-mode] huge files In-Reply-To: <4F3B6E1C.5080307@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Wed, 15 Feb 2012 09:34:36 +0100") References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> Message-ID: <87wr7ow2vt.fsf@iro.umontreal.ca> Andreas R?hler writes: > Am 14.02.2012 22:31, schrieb Andrea Crotti: >> python-mode.el is > 10k lines now, which for me causes two problems: >> - it's hard to even know the various functionalities >> - it's hard to manage the file As I'm favoring a single file, I feel like arguing a bit, not much :-). In any case, as Barry and Jeff said already, this is Andreas' now. The first point is a documentation and organization issue. The documentation is severely lacking, and it should exist either in some more substantial README, or a manual. The size of the Emacs Lisp source does not much have to do with it. It could it either be split to stress the structure, or merely organized into pages, which would have almost the same effect. The second point, I do not get. How is it hard to manage a single file? It seems to be that many files are harder to manage than one. On the other hand, python-mode already holds a few extraneous Emacs Lisp files taken from elsewhere, so the simplicity is being lost already. Splitting python-mode in many files might blur the distinction between what is python-mode proper from what is borrowed stuff; such blurring have both advantages and disadvantages, but this is another problem. >> Since it doesn't do any difference in terms of performance and it's >> much less intimidating to try to grasp, is there a reason to keep all in >> one big file? It's easier to share and install. A bit, not by much, nowadays. Splitting might be a trigger towards a more formal installation procedure. But it would not alleviate the need for some good, or at least reasonable documentation. Splitting could also give to some the feeling that it "replaces" documentation. So I fear a bit that energies might be dispersed away from the real thing to do. Fran?ois From andreas.roehler at online.de Wed Feb 15 18:21:43 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Wed, 15 Feb 2012 18:21:43 +0100 Subject: [Python-mode] huge files In-Reply-To: <20120215075746.00946510@resist.wooz.org> References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> <20120215075746.00946510@resist.wooz.org> Message-ID: <4F3BE9A7.5080303@online.de> Am 15.02.2012 13:57, schrieb Barry Warsaw: > On Feb 15, 2012, at 09:34 AM, Andreas R?hler wrote: > >> think it's basically historical. >> >> People interested in developing/understanding might check out and use the components branch >> >> https://code.launchpad.net/~a-roehler/python-mode/components-python-mode >> >> I'm doing all my developing and Python editing there. >> It's sometimes ahead several days, if new features are introduced. But the same tests are run before commits, so a possible loss in stability is mince. >> >> BTW in future we could create a declared stable branch of components and make two tarballs for release. > > I've always thought that because python-mode.el is a separate download, it's > better to have one big file. This makes it easier for users to add it to > their Emacsen, even though it makes it more difficult to maintain, as rightly > observed. > > But maybe we're at the tipping point where that trade-off should go the other > way. Good, discoverable, installation documentation would go a long way > toward alleviating those concerns. I run python-mode out of the bzr trunk, so > I'm probably not a good use case. > > In a very real sense, this is Andreas's decision now. "He who does the work, > decides" and Andreas has for quite a while now assumed primary ownership on > the code, by virtue of his great work on the mode. I have no place to stand > in the way of his decision on this. > > Cheers, > -Barry thanks looking with patience at my endeavors :) Changed the intro note at lp, which mentions now a developing branch beneath the trunk. Concerning the one-file-solution see the pro at the users side. BTW as for patches sent, the branch wouldn't be of importance so far. The only point is the being against a current revision. Cheers, Andreas From andrea.crotti.0 at gmail.com Wed Feb 15 20:00:39 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Wed, 15 Feb 2012 19:00:39 +0000 Subject: [Python-mode] huge files In-Reply-To: <87wr7ow2vt.fsf@iro.umontreal.ca> References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> <87wr7ow2vt.fsf@iro.umontreal.ca> Message-ID: <4F3C00D7.9070009@gmail.com> On 02/15/2012 03:08 PM, Fran?ois Pinard wrote: > It's easier to share and install. A bit, not by much, nowadays. > Splitting might be a trigger towards a more formal installation > procedure. But it would not alleviate the need for some good, or at > least reasonable documentation. Splitting could also give to some the > feeling that it "replaces" documentation. So I fear a bit that energies > might be dispersed away from the real thing to do. > > I don't think that the single file should disappear, what I just would like is that if I'm downloading from bazaar I see all the components, which is also how Andreas is actually working. It's still easy to produce one single file for deployment, if that turns out to be better. And really, 10k lines of code is not good, in any language, because it's impossible just have a look at the file and understand (even very approximatively) what is going on. From pinard at iro.umontreal.ca Wed Feb 15 20:59:11 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Wed, 15 Feb 2012 14:59:11 -0500 Subject: [Python-mode] huge files In-Reply-To: <4F3C00D7.9070009@gmail.com> (Andrea Crotti's message of "Wed, 15 Feb 2012 19:00:39 +0000") References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> <87wr7ow2vt.fsf@iro.umontreal.ca> <4F3C00D7.9070009@gmail.com> Message-ID: <87ipj7x3zk.fsf@iro.umontreal.ca> Andrea Crotti writes: > And really, 10k lines of code is not good, in any language, because > it's impossible just have a look at the file and understand (even very > approximatively) what is going on. Hi, Andrea. I really believe that there are ways to organize and document a big file so it is clear, legible, and manageable. It all depends on the code. Gnus or Org could not be bundled as a single file. Next to these, Python mode is still a tiny thing. Splitting a small project in parts might augment the editing hurdle. If the original file is disorganised, splitting it might organise it a bit, but overall, this would only very marginally improve it. If there is a problem in the area of clarity and legibility, splitting is really not going to solve it in a significant way. This would be a wrong approach for a real problem. Oh, no doubt that there might be other good reasons to split. But as far as the quality of the documentation is meant, it would not buy us much, and might only induce useless delays. Fran?ois From andreas.roehler at online.de Wed Feb 15 22:15:09 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Wed, 15 Feb 2012 22:15:09 +0100 Subject: [Python-mode] huge files In-Reply-To: <87ipj7x3zk.fsf@iro.umontreal.ca> References: <4F3AD2CE.5050903@gmail.com> <4F3B6E1C.5080307@online.de> <87wr7ow2vt.fsf@iro.umontreal.ca> <4F3C00D7.9070009@gmail.com> <87ipj7x3zk.fsf@iro.umontreal.ca> Message-ID: <4F3C205D.9080009@online.de> Am 15.02.2012 20:59, schrieb Fran?ois Pinard: > Andrea Crotti writes: > >> And really, 10k lines of code is not good, in any language, because >> it's impossible just have a look at the file and understand (even very >> approximatively) what is going on. > > Hi, Andrea. > > I really believe that there are ways to organize and document a big file > so it is clear, legible, and manageable. > updated doc/commands-python-mode.org which should deliver some overview. > It all depends on the code. Gnus or Org could not be bundled as a > single file. Next to these, Python mode is still a tiny thing. > > Splitting a small project in parts might augment the editing hurdle. If > the original file is disorganised, splitting it might organise it a bit, > but overall, this would only very marginally improve it. > > If there is a problem in the area of clarity and legibility, splitting > is really not going to solve it in a significant way. This would be a > wrong approach for a real problem. > > Oh, no doubt that there might be other good reasons to split. But as > far as the quality of the documentation is meant, it would not buy us > much, and might only induce useless delays. > > Fran?ois > > > > From andreas.roehler at online.de Thu Feb 16 10:31:17 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Thu, 16 Feb 2012 10:31:17 +0100 Subject: [Python-mode] huge files In-Reply-To: <4F3AD2CE.5050903@gmail.com> References: <4F3AD2CE.5050903@gmail.com> Message-ID: <4F3CCCE5.1040906@online.de> [ ... ] > much less intimidating to try to grasp, [ ... ] Added a README.DEVEL, indicating some entry point for people who want to dig into the code. Cheers, Andreas From andreas.roehler at online.de Fri Feb 17 08:19:48 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 17 Feb 2012 08:19:48 +0100 Subject: [Python-mode] [IPython-User] Status of ipython.el and relationship with python-mode.el In-Reply-To: <1329420903421-4477349.post@n6.nabble.com> References: <1329420903421-4477349.post@n6.nabble.com> Message-ID: <4F3DFF94.9020504@online.de> Am 16.02.2012 20:35, schrieb rosoloum: > In reading this thread in StackOverflow: > "IPython Emacs Integration": > http://stackoverflow.com/questions/8226493/ipython-emacs-integration > > I learned that ipython.el is known to be out of date, and that the IPython > community is working on a fix. More specifically the accepted answer in > StackOverflow points to this other thread in github: > "Emacs freezes when tab is hit in ipython with latest python-mode": > https://github.com/ipython/ipython/pull/1015 > Hi, some remarks being one of the python-mode.el developers and definitly the cupable having merged the ipython.el stuff - thanks a lot to the ipython.el people BTW. The idea is to provide a solution already for the Emacs beginner, taking the need for several customizations, loading across the net etc. A Python-mode should assist all common flavors of Python right from the spot. Think we should be able to keep the modes compatible. Should you have suggestions, how to design python-mode.el in order to meet your needs, it's welcome. Please send your suggestions, bug reports etc. https://bugs.launchpad.net/python-mode Certainly we will fix bugs when being aware of a report at other places too. Should people want to CC me with (i)python-mode related stuff from other places, that's okay for me, might be helpful too. Cheers, Andreas -- http://launchpad.net/python-mode http://launchpad.net/s-x-emacs-werkstatt/ > It looks like there was some substantial activity in that github thread, but > I couldn't find any references to the fixes mentioned in the thread in the > mailing list archives for users or devs, nor a follow-up discussion. > > With this, I have a few, hopefully short questions: > * What is the status of the fixes to ipython.el? > * Is ipython.el now bundled withing the ipython package? Is there a site > where I can track the progress in this direction? (the github thread above > seems to be closed) > * Does ipython.el need python-mode.el to work? > > Thanks so much for the great work. > > > -- > View this message in context: http://python.6.n6.nabble.com/Status-of-ipython-el-and-relationship-with-python-mode-el-tp4477349p4477349.html > Sent from the IPython - User mailing list archive at Nabble.com. > _______________________________________________ > IPython-User mailing list > IPython-User at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-user > From andreas.roehler at online.de Sat Feb 25 21:36:50 2012 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Sat, 25 Feb 2012 21:36:50 +0100 Subject: [Python-mode] Python-mode guess-indent API change Message-ID: <4F494662.7030103@online.de> Hi Barry, hi all, with resp. to a possibly reduced complexity IMO Python-mode should not guess `py-indent-offset' when loading already. It simply makes no sense to pick that from one spot, as every block may have a different one. OTOH when one of the functions needing it like `py-compute-indentation' is called, all these functions can't used pre-calculated indents anyway - for the very reason. See a bug report lp:902890 requiring it though. WDYT? Andreas