From Tom_Roche at pobox.com Mon Jan 2 17:38:58 2012 From: Tom_Roche at pobox.com (Tom Roche) Date: Mon, 02 Jan 2012 11:38:58 -0500 Subject: [Python-mode] re/install howto? References: <4EFEC52A.1040509@online.de> Message-ID: <87ipkuawkd.fsf@pobox.com> Andreas R?hler Sat, 31 Dec 2011 09:17:46 +0100 > new release is available Given the release of fixes for pymacs install (formerly a separate prereq), and also that I'm now on emacs-24, I'd like to try reinstalling python-mode and all its prerequisites. However I'm not seeing install instructions, much less reinstall instructions, on the website. (Notably https://answers.launchpad.net/python-mode/+faqs is empty.) I note http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/view/head:/INSTALL > Put the respective lines into your Emacs initialisation file: > (add-to-list 'load-path "PATH/TO/PYTHON-MODE/") > (setq py-install-directory "PATH/TO/PYTHON-MODE/") > (require 'python-mode) but am wondering if one must do * anything with the included setup.py * something to setup the now-included pymacs TIA, Tom Roche From andreas.roehler at online.de Mon Jan 2 18:43:32 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Mon, 02 Jan 2012 18:43:32 +0100 Subject: [Python-mode] re/install howto? In-Reply-To: <87ipkuawkd.fsf@pobox.com> References: <4EFEC52A.1040509@online.de> <87ipkuawkd.fsf@pobox.com> Message-ID: <4F01ECC4.5030402@online.de> Am 02.01.2012 17:38, schrieb Tom Roche: > > Andreas R?hler Sat, 31 Dec 2011 09:17:46 +0100 >> new release is available > > Given the release of fixes for pymacs install (formerly a separate > prereq), and also that I'm now on emacs-24, I'd like to try > reinstalling python-mode and all its prerequisites. However I'm not > seeing install instructions, much less reinstall instructions, on the > website. (Notably > > https://answers.launchpad.net/python-mode/+faqs > > is empty.) I note > > http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/view/head:/INSTALL >> Put the respective lines into your Emacs initialisation file: > >> (add-to-list 'load-path "PATH/TO/PYTHON-MODE/") >> (setq py-install-directory "PATH/TO/PYTHON-MODE/") >> (require 'python-mode) > > but am wondering if one must do > > * anything with the included setup.py > delivered INSTALL should mention all needed > * something to setup the now-included pymacs please make up a question in section https://answers.launchpad.net/python-mode will keep the answer than in faq also missing Pymacs note is worth a bug report when py-load-pymacs-p is set to `t', pymacs-eval for example works here out of the box. Nonetheless Pymacs-integration needs some work still. Installing Pymacs separately might be the better choice for the moment. thanks, Andreas > > TIA, Tom Roche > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From ramestica at lavabit.com Wed Jan 11 05:49:19 2012 From: ramestica at lavabit.com (Rodrigo Amestica) Date: Tue, 10 Jan 2012 23:49:19 -0500 Subject: [Python-mode] ipython on remote host Message-ID: my shell of choice is ipyhon, therefore, I set py-shell-name as "ipython". Is there any way to run the shell in a remote host? The python files I'm editing are normally already in that same remote host which I access through tramp. thanks, Rodrigo From andreas.roehler at online.de Thu Jan 12 18:56:14 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Thu, 12 Jan 2012 18:56:14 +0100 Subject: [Python-mode] python-mode customization group In-Reply-To: References: <20120111064920.21606.89848.malonedeb@wampee.canonical.com> <20120112135123.10819.57402.malone@wampee.canonical.com> Message-ID: <4F0F1EBE.8060202@online.de> Hi Barry, hi all, after implementing the patch below --thanks Richard-- found that mixture of python-mode.el and python.el customization slots confusing. After introducing a python-mode customization group it looks much better. Will commit it next, so you may have a look. Cheers, Andreas Am 12.01.2012 15:41, schrieb Richard Everson: > Here's a little addition that makes customisation a bit easier -- I got > fed up with Customize->Programming->Languages->Python > > > $ bzr diff -p1 > === modified file 'python-mode.el' > --- old/python-mode.el 2012-01-12 13:31:48 +0000 > +++ new/python-mode.el 2012-01-12 14:35:36 +0000 > @@ -1271,7 +1271,11 @@ > ["Find function" py-find-function > :help "Try to find source definition of function at point"] > ["Update imports" py-update-imports > - :help "Update list of top-level imports for completion"])) > + :help "Update list of top-level imports for completion"] > + "-" > + ["Customize Python mode" (customize-group 'python) > + :help "Open the customization buffer for Python"] > + )) > map)) > ;; Fixme: add toolbar stuff for useful things like symbol help, send > ;; region, at least. (Shouldn't be specific to Python, obviously.) > > > Best, > Richard. From not0read0765 at yopmail.com Thu Jan 19 08:48:35 2012 From: not0read0765 at yopmail.com (olive) Date: Thu, 19 Jan 2012 08:48:35 +0100 Subject: [Python-mode] How to keeps emacs from launching a python shell Message-ID: <20120119084835.78345d80@yopmail.com> I am using python-mode.el to edit python scripts (with FSF Gnu emacs 23.3). Each time emacs enter python mode, it launches a python interpreter (not visible by default but it is launched). Is it possible to prevent that? I would like to be able to launch the interpreter when I want it but not always by default. Olive From not0read0765 at yopmail.com Thu Jan 19 11:07:37 2012 From: not0read0765 at yopmail.com (olive) Date: Thu, 19 Jan 2012 11:07:37 +0100 Subject: [Python-mode] How to keeps emacs from launching a python shell In-Reply-To: <20120119084835.78345d80@yopmail.com> References: <20120119084835.78345d80@yopmail.com> Message-ID: <20120119110737.032ba7ce@yopmail.com> On Thu, 19 Jan 2012 08:48:35 +0100 olive wrote: > I am using python-mode.el to edit python scripts (with FSF Gnu > emacs 23.3). Each time emacs enter python mode, it launches a python > interpreter (not visible by default but it is launched). Is it > possible to prevent that? I would like to be able to launch the > interpreter when I want it but not always by default. > > Olive I have just found the answer myself: py-start-run-py-shell , sorry... Olive From andreas.roehler at online.de Thu Jan 19 16:37:24 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Thu, 19 Jan 2012 16:37:24 +0100 Subject: [Python-mode] How to keeps emacs from launching a python shell In-Reply-To: <20120119110737.032ba7ce@yopmail.com> References: <20120119084835.78345d80@yopmail.com> <20120119110737.032ba7ce@yopmail.com> Message-ID: <4F1838B4.3050108@online.de> Am 19.01.2012 11:07, schrieb olive: > On Thu, 19 Jan 2012 08:48:35 +0100 > olive wrote: > >> I am using python-mode.el to edit python scripts (with FSF Gnu >> emacs 23.3). Each time emacs enter python mode, it launches a python >> interpreter (not visible by default but it is launched). Is it >> possible to prevent that? I would like to be able to launch the >> interpreter when I want it but not always by default. >> >> Olive > > I have just found the answer myself: py-start-run-py-shell , sorry... > > Olive we should have a feature list and better documentation. thanks being patient ;) Andreas From andreas.roehler at online.de Fri Jan 20 13:54:29 2012 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Fri, 20 Jan 2012 13:54:29 +0100 Subject: [Python-mode] virtualenv support Message-ID: <4F196405.5060003@online.de> Hi Barry, hi all, consider merging Gabriele Lanaro's https://github.com/pdee/pdee/blob/master/extensions/virtualenv.el into python-mode.el next days. Made a Blueprint for this https://blueprints.launchpad.net/python-mode/+spec/virtualenv taking feature requests etc. still Thanks Gabriele BTW, Andreas From yagnesh at live.com Fri Jan 20 14:49:09 2012 From: yagnesh at live.com (Yagnesh Raghava Yakkala) Date: Fri, 20 Jan 2012 22:49:09 +0900 Subject: [Python-mode] few python-mode questions Message-ID: <877h0mmqlm.fsf@live.com> Hello Andreas and all, I would like to use python-mode for my work. I have few questions and hope to get few comments and suggestion and prior apologies for very basic questions and long mail. Consider me as a noob at Python and python-mode but not to the Emacs. I need to write code only in Python3. Right now I have only one line customization for python-mode in my .emacs i.e, ,---- | (require 'python-mode) `---- and I have Python 3.2.2, ipython 0.11.2 and Emacs from bzr trunk. with that intro my questions are, 1) `py-shell-name' to "ipython" I see ipython is working great with in the Emacs. But even if I set (setq py-shell-name "ipython") and press a C-c C-c in Python buffer it still is not taking to *IPython* buffer. how can I use ipython as my Python shell 2) auto completion: what exactly I should have in my .emacs to get auto completion in python-mode. Again auto-completion with TAB working great in *IPython* buffer but not python-mode. I see the difficulty of getting auto-completion in python-mode buffer and auto completion helper function should know the type of the object at point to get the correct list of possible completions. My instinct was to why not use "ipython" for receiving auto completions. 3) how to refer python-mode: Stupid question but I am asking because different modes and names floating around for Python. more questions to follow once I figure out these PS: Many thanks to python-mode developers especially to Andreas for the hard work you put on this mode. Thanks -- Yagnesh From barry at python.org Fri Jan 20 15:52:04 2012 From: barry at python.org (Barry Warsaw) Date: Fri, 20 Jan 2012 09:52:04 -0500 Subject: [Python-mode] virtualenv support In-Reply-To: <4F196405.5060003@online.de> References: <4F196405.5060003@online.de> Message-ID: <20120120095204.1d1c24c4@resist.wooz.org> On Jan 20, 2012, at 01:54 PM, Andreas R?hler wrote: >Hi Barry, hi all, >consider merging Gabriele Lanaro's >https://github.com/pdee/pdee/blob/master/extensions/virtualenv.el >into python-mode.el next days. >Made a Blueprint for this >https://blueprints.launchpad.net/python-mode/+spec/virtualenv >taking feature requests etc. still Interesting! I love virtualenv, but hadn't considered support for it in my Emacs. 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 andreas.roehler at online.de Fri Jan 20 19:42:55 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 20 Jan 2012 19:42:55 +0100 Subject: [Python-mode] few python-mode questions In-Reply-To: <877h0mmqlm.fsf@live.com> References: <877h0mmqlm.fsf@live.com> Message-ID: <4F19B5AF.6020000@online.de> Am 20.01.2012 14:49, schrieb Yagnesh Raghava Yakkala: > > Hello Andreas and all, > > I would like to use python-mode for my work. I have few questions and hope > to get few comments and suggestion and prior apologies for very basic > questions and long mail. > > Consider me as a noob at Python and python-mode but not to the Emacs. I > need to write code only in Python3. Right now I have only one line > customization for python-mode in my .emacs i.e, > > ,---- > | (require 'python-mode) > `---- > > and I have Python 3.2.2, ipython 0.11.2 and Emacs from bzr trunk. > Hi Yagnesh, in order to use python-mode we are developing here, you must download http://launchpad.net/python-mode/trunk/6.0.4/+download/python-mode.el-6.0.4.tar.gz or the current trunk with bazaar bzr branch lp:python-mode This python-mode.el owes a lot to python.el coming with Emacs, but has much more features. have a look at the commands-list in directory doc > with that intro my questions are, > > 1) `py-shell-name' to "ipython" > I see ipython is working great with in the Emacs. But even if I set > (setq py-shell-name "ipython") and press a C-c C-c in Python buffer > it still is not taking to *IPython* buffer. how can I use ipython as > my Python shell > that reads you have python-mode.el already, as py-shell-name only exists here AFAIK Read the INSTALL file how to set the path in your Emacs init. In order to get an existing shell just do M-x MY-SHELL-NAME > 2) auto completion: > > what exactly I should have in my .emacs to get auto completion in > python-mode. Again auto-completion with TAB working great in *IPython* > buffer but not python-mode. > Presently we have completion, not auto-completion, i.e. completion needs a key, TAB in shells and M-TAB in common buffers. Should it not work, please send a bug report. So far, good luck, Andreas > I see the difficulty of getting auto-completion in python-mode > buffer and auto completion helper function should know the type of the > object at point to get the correct list of possible completions. My > instinct was to why not use "ipython" for receiving auto > completions. > > 3) how to refer python-mode: > > Stupid question but I am asking because different modes and names floating > around for Python. > > more questions to follow once I figure out these > > PS: Many thanks to python-mode developers especially to Andreas for the > hard work you put on this mode. > > Thanks > > -- > Yagnesh > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From justin.caratzas at gmail.com Fri Jan 20 17:33:04 2012 From: justin.caratzas at gmail.com (Justin Caratzas) Date: Fri, 20 Jan 2012 11:33:04 -0500 Subject: [Python-mode] virtualenv support References: <4F196405.5060003@online.de> <20120120095204.1d1c24c4@resist.wooz.org> Message-ID: <87obtywczj.fsf@gmail.com> Barry Warsaw writes: > On Jan 20, 2012, at 01:54 PM, Andreas R?hler wrote: > >>Hi Barry, hi all, >>consider merging Gabriele Lanaro's >>https://github.com/pdee/pdee/blob/master/extensions/virtualenv.el >>into python-mode.el next days. >>Made a Blueprint for this >>https://blueprints.launchpad.net/python-mode/+spec/virtualenv >>taking feature requests etc. still > > Interesting! I love virtualenv, but hadn't considered support for it in my > Emacs. > > Cheers, > -Barry Are we talking about merging the code in, or adding as a dependency? -- justin From andreas.roehler at online.de Fri Jan 20 20:51:03 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 20 Jan 2012 20:51:03 +0100 Subject: [Python-mode] virtualenv support In-Reply-To: <87obtywczj.fsf@gmail.com> References: <4F196405.5060003@online.de> <20120120095204.1d1c24c4@resist.wooz.org> <87obtywczj.fsf@gmail.com> Message-ID: <4F19C5A7.1030700@online.de> Am 20.01.2012 17:33, schrieb Justin Caratzas: > > Barry Warsaw writes: > >> On Jan 20, 2012, at 01:54 PM, Andreas R?hler wrote: >> >>> Hi Barry, hi all, >>> consider merging Gabriele Lanaro's >>> https://github.com/pdee/pdee/blob/master/extensions/virtualenv.el >>> into python-mode.el next days. >>> Made a Blueprint for this >>> https://blueprints.launchpad.net/python-mode/+spec/virtualenv >>> taking feature requests etc. still >> >> Interesting! I love virtualenv, but hadn't considered support for it in my >> Emacs. >> >> Cheers, >> -Barry > > Are we talking about merging the code in, or adding as a dependency? > > -- justin > > Hi, as for the components-branch it gets bundled as is already at git at github.com:pdee/pdee.git, default pdee Don't know yet for python-mode.el here, both is possible. Do you have any preferences? Maybe Barry has? Cheers, Andreas From yagnesh at live.com Sat Jan 21 19:47:33 2012 From: yagnesh at live.com (Yagnesh Raghava Yakkala) Date: Sun, 22 Jan 2012 03:47:33 +0900 Subject: [Python-mode] few python-mode questions References: <877h0mmqlm.fsf@live.com> <4F19B5AF.6020000@online.de> Message-ID: <87sjj87v0a.fsf@live.com> Hi Andreas., Thank you very much for the reply., Andreas R?hler writes: [...] > Hi Yagnesh, > > in order to use python-mode we are developing here, you must download > > http://launchpad.net/python-mode/trunk/6.0.4/+download/python-mode.el-6.0.4.tar.gz > I forgot to mention in my original mail, I have installed python-mode with the help of el-get from a git mirror (https://github.com/emacsmirror/python-mode) which generally follows launchpad trunk. right now it seems two commits lag behind. (I believe I installed python-mode properly) > or the current trunk with bazaar > > bzr branch lp:python-mode > > This python-mode.el owes a lot to python.el coming with Emacs, but has > much more features. I am aware of that. Thank you. > [...] >> >> what exactly I should have in my .emacs to get auto completion in >> python-mode. Again auto-completion with TAB working great in *IPython* >> buffer but not python-mode. >> > > Presently we have completion, not auto-completion, i.e. completion > needs a key, TAB in shells and M-TAB in common buffers. > > Should it not work, please send a bug report. I understand I mixed up the terms. my intention was to refer "completion" only at this point. let me try to explain what I was talking about. I loaded "minimal.el" which contains following lines $ emacs -q -l ~/.emacs.d/minimal.el ----------------------------------------------------------------- (add-to-list 'load-path "~/.emacs.d/el-get/python-mode") (setq py-install-directory "~/.emacs.d/el-get/python-mode") (require 'python-mode) ;;; some convinience (ido-mode) (defalias 'yes-or-no-p 'y-or-n-p) ----------------------------------------------------------------- now created new python file "test.py" wrote these lines ----------------------------------------------------------------- #!/usr/bin/env python3 a = "b" a.| ----------------------------------------------------------------- my cursor is at "|". saved the buffer. I see a *Python* buffer was created as soon as I saved test.py. when I press "TAB" nothing happens. what I expect is similer to what is happening in *ipython* shell. explained down below Now M-X ipython ,----[ipython] | | In [1]: a = "b" | | In [2]: a | Out[2]: 'b' | | In [3]: a.| `---- if I type TAB at "|" I see another buffer called *Python Completion* pops up with offering follwing completions. ,---- | a.capitalize a.center a.count a.encode | a.endswith a.expandtabs a.find a.format | a.format_map a.index a.isalnum a.isalpha | a.isdecimal a.isdigit a.isidentifier a.islower | a.isnumeric a.isprintable a.isspace a.istitle | a.isupper a.join a.ljust a.lower | a.lstrip a.maketrans a.partition a.replace | a.rfind a.rindex a.rjust a.rpartition | a.rsplit a.rstrip a.split a.splitlines | a.startswith a.strip a.swapcase a.title | a.translate a.upper a.zfill `---- So how can I get similar thing in *test.py* buffer itselt I hope my description is clear. -- Yagnesh From andreas.roehler at online.de Sun Jan 22 10:05:36 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 22 Jan 2012 10:05:36 +0100 Subject: [Python-mode] was: Re: [Bug 916869] tab completion in Ipython buffers In-Reply-To: <11DAD36E-D9D1-474D-923E-85035A64578F@exeter.ac.uk> References: <20120115181256.10917.94011.malonedeb@wampee.canonical.com> <20120120215502.28646.36675.malone@chaenomeles.canonical.com> <11DAD36E-D9D1-474D-923E-85035A64578F@exeter.ac.uk> Message-ID: <4F1BD160.6040406@online.de> Am 21.01.2012 19:10, schrieb Richard Everson: [ ... ] Hi Richard, thanks a lot for the patch. Could not look at it closer yet; just some ideas, as the completion issues affects other reports/request too, true auto-completion is ahead. (completion-at-point) says: "Complete the thing at point according to local mode. This runs the hook `completion-at-point-functions' until a member returns non-nil." That's basically the proceeding I'm heading to: py-complete-function should hand over a list of completion-functions sorted with resp. to environment. So far just an idea. As sometimes it might not be obvious what's the best path to choose, it might be of interest having alternatives. Should you reach a point where you want to see something, while a different path has been chosen here, please don't hesitate to open a personal branch, so we may play with it. All you need AFAIK is applying to be member of the team, which is nothing more than a formality. Afterwards bzr push lp:~MY-NAME/python-mode/MY-BRANCH should do it. So far from this morning, Cheers, Andreas From yagnesh at live.com Sun Jan 22 19:22:51 2012 From: yagnesh at live.com (Yagnesh Raghava Yakkala) Date: Mon, 23 Jan 2012 03:22:51 +0900 Subject: [Python-mode] was: Re: [Bug 916869] tab completion in Ipython buffers References: <20120115181256.10917.94011.malonedeb@wampee.canonical.com> <20120120215502.28646.36675.malone@chaenomeles.canonical.com> <11DAD36E-D9D1-474D-923E-85035A64578F@exeter.ac.uk> <4F1BD160.6040406@online.de> Message-ID: <87hazn7g1w.fsf@live.com> Hello Andreas & Richard, sorry for jumping in. I just filed a bug[1] report and found out that this discussion is very much related to where I was heading to although I haven't checked the Richard patch thoroughly. Andreas R?hler writes: > Am 21.01.2012 19:10, schrieb Richard Everson: > [ ... ] > Hi Richard, > > thanks a lot for the patch. > > Could not look at it closer yet; just some ideas, as the completion > issues affects other reports/request too, true auto-completion is > ahead. > > > (completion-at-point) says: > > "Complete the thing at point according to local mode. > This runs the hook `completion-at-point-functions' until a member > returns non-nil." > > That's basically the proceeding I'm heading to: py-complete-function > should hand over a list of completion-functions sorted with resp. to > environment. > > So far just an idea. I think its very good idea and it would make completion thing more consistent with whole emacs. > > As sometimes it might not be obvious what's the best path to choose, > it might be of interest having alternatives. Should you reach a point > where you want to see something, while a different path has been > chosen here, please don't hesitate to open a personal branch, so we > may play with it. All you need AFAIK is applying to be member of the > team, which is nothing more than a formality. > > Afterwards > > bzr push lp:~MY-NAME/python-mode/MY-BRANCH > > should do it. > > So far from this morning, > Cheers, > > Andreas Footnotes: [1] https://bugs.launchpad.net/python-mode/+bug/920079 -- YYR From andreas.roehler at online.de Mon Jan 23 09:25:24 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Mon, 23 Jan 2012 09:25:24 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87hazn9g4d.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> Message-ID: <4F1D1974.5020902@online.de> Am 23.01.2012 05:50, schrieb Fran?ois Pinard: [ ... ] > Hi, Andreas (hello, Barry!) > > I'm revisiting this under a new angle, as I now intend to try using > Emacs for Python development for a while, to see how it goes. I used to > use Vim for a few years, and more recently, Wing IDE, which by the way, > is nice. Except that it requires some stunts to adapt it to my needs > (while Vim or Emacs are more customizable), and the maintainers, who are > quite responsive on the average, are reluctant to recognize a few bugs > as such, so I sometimes feel stuck. Free software has virtues! :-) > > Org mode brought me back to Emacs for many things, and one thing leading > to another, here I am, a possibly fresh, reborn python-mode.el user. > Hi Fran?ois, really good news! While completion now might be done alternatively, Pymacs based py-complete feels faster. Relates also to the other proceedings. Always in favor of Pymacs :) > It seems that one problem you met is that Pymacs installs a Python > package, having only pymacs.py besides __init__.py, while you prefer a > single pymac.py file. I thought that people might want to install their > Pymacs specific files within that package. There are alternate means, > like specifying within Emacs an extra load-path for Python modules. As > I have no evidence that the Pymacs package is used as such, maybe that > __init__.py is overkill. I should ask Pymacs users. Cc:ed! :-). > > Another problem you might have with Pymacs is that it is now > pre-processed, there is no more a "single pymacs.py fits all". Python 3 > and Jython introduced incompatible syntax to the point a single file may > not be stretched to do for all cases, even through 2to3 (the needed > stunts would become just too ugly). > > Earlier today, I compared the Pymacs copy within python-mode.el trunk > with mine, and the python-mode.el lags slightly, nothing important yet. > But it might become a problem, as we cannot have two copies of Pymacs at > once in the same Emacs session. Another problem is that python-mode > freezes a particular pre-processing of pymacs.py, which is good for most > recent Python 2.x versions, but not as universal as one would hope. > >>> If I understand correctly, I think that's the best way to go. >>> python-mode.el itself shouldn't require pymacs, > >> Agree. Nonetheless it was always required, as pycomplete relied on >> it. That changed only recently. Basic completion with M-TAB now works >> out from python-mode.el alone. > > I do not understand python-mode.el enough yet to see how it uses Pymacs. > If Pymacs launches a pymacs-helper, and if Emacs launches an "inferior > Python shell", and M-x pdb its own as well, I presume that all these > Python processes do not inter-operate nicely, while they should, at > least if they all execute the same pieces of Python code. Moreover, in > my case, these "pieces" may sometimes be fairly big packages. While > Pymacs may be useful to attempt completion or inspection, and other > things, *not* having it around reduces the size of the above puzzle. > What about to maintain and release a one-file Python-mode and a fule scale integrated project? I.e having two download-files. In earlier times that happened AFAIK. We may take a Pymacs-branch which contains a synced python-mode.el I'll remove the mini-Pymacs install from python-mode.el [ ... ] > > It might worth aiming that python-mode's Pymacs and the Pymacs under Git > be almost kept in sync. If some (simple) changes on my side could make > this easier without hurting other Pymacs users, let's ponder them. > > It would not be much fun, I guess, if python-mode has to repeat the > configuration and make machinery of the Pymacs distribution, while I do > not see how it could be avoided without creating problems here or there. > Expecting users to explicitly, separately install Pymacs is no fun > either. I do not know where lies the wiser wisdom! > > Fran?ois > > P.S. Feel free to copy this discussion on the python-mode mailing list > if you think it would be a good thing to do. > A question around Make: If we provide the next Python-mode/Pymacs release using Make as Pymacs does, the top directory should contain only the minimal requiring, i.e, INSTALL, README etc. Cheers, Andreas From pinard at iro.umontreal.ca Mon Jan 23 18:40:31 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Mon, 23 Jan 2012 12:40:31 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F1D1974.5020902@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Mon, 23 Jan 2012 09:25:24 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> Message-ID: <87obtu48s0.fsf@iro.umontreal.ca> Andreas R?hler writes: >> Org mode brought me back to Emacs for many things, and one thing leading >> to another, here I am, a possibly fresh, reborn python-mode.el user. > Hi Fran?ois, really good news! Are you sure? ;-) I'll likely begin to ramble and moan about everything! You might prefer me /silent/! :-) >> * Pymacs installs a Python package [... rather than a single file ...] >> * Pymacs is [...] now pre-processed [...] >> * the Pymacs within python-mode.el trunk lags slightly [...] > What about to maintain and release a one-file Python-mode and a full > scale integrated project? I'm not sure I understand your vision. What would that be? How could we make things simple and dependable? >> If Pymacs launches a pymacs-helper, and if Emacs launches an "inferior >> Python shell", and M-x pdb its own as well, I presume that all these >> Python processes do not inter-operate nicely [...] That seems like a serious problem to me. Regardless of Pymacs, I wonder if (and hope that) pdb and an inferior Python share data and state. It seems to me that it might become fairly tedious otherwise. I do not know yet, I have to try and explore python-mode usage for real :-). If Pymacs is merely used for completion because it is speedier (cannot be *that* speedy anyway!), maybe that Pymacs tricks maybe repeated without it? That would yield a tighter integration between the remaining Python processes, so python-mode stays more useful. Currently, Pymacs starts its helper as a standalone Python program, which is also quite disconnected from data and state of an inferior Python or pdb interaction buffer. Not much useful. An idea, maybe! I do not know how doable it would be: maybe Pymacs should have some operational mode by which it starts a new thread in an already existing program, and as such, opening a window into it. It surely cannot install itself on the main thread then, which is often reserved for GUI interactions and such things. Maybe threaded programs want full control over their threads, and would squash Pymacs at the first opportunity? Maybe a Pymacs thread would mess program termination? Maybe this is a big can of worms, I do not know. Fran?ois P.S. There are interesting and tempting problems in there, but I have so little free time. Sigh! From andreas.roehler at online.de Mon Jan 23 21:14:02 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Mon, 23 Jan 2012 21:14:02 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87obtu48s0.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> Message-ID: <4F1DBF8A.7040207@online.de> Am 23.01.2012 18:40, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >>> Org mode brought me back to Emacs for many things, and one thing leading >>> to another, here I am, a possibly fresh, reborn python-mode.el user. > >> Hi Fran?ois, really good news! > > Are you sure? ;-) I'll likely begin to ramble and moan about everything! > You might prefer me /silent/! :-) > if you could manage to moan into the bug-tracker, that will be great :) >>> * Pymacs installs a Python package [... rather than a single file ...] >>> * Pymacs is [...] now pre-processed [...] >>> * the Pymacs within python-mode.el trunk lags slightly [...] > >> What about to maintain and release a one-file Python-mode and a full >> scale integrated project? > > I'm not sure I understand your vision. What would that be? How could > we make things simple and dependable? > Existing python-mode should not disturb installed Pymacs. Does it? If yes, please make a report at https://bugs.launchpad.net/python-mode If not, next step might be a repo, keeping/installing Pymacs alongside with our stuff. >>> If Pymacs launches a pymacs-helper, and if Emacs launches an "inferior >>> Python shell", and M-x pdb its own as well, I presume that all these >>> Python processes do not inter-operate nicely [...] > > That seems like a serious problem to me. Regardless of Pymacs, I wonder > if (and hope that) pdb and an inferior Python share data and state. It > seems to me that it might become fairly tedious otherwise. I do not > know yet, I have to try and explore python-mode usage for real :-). Fine. > > If Pymacs is merely used for completion because it is speedier (cannot > be *that* speedy anyway!), maybe that Pymacs tricks maybe repeated > without it? That would yield a tighter integration between the > remaining Python processes, so python-mode stays more useful. > > Currently, Pymacs starts its helper as a standalone Python program, > which is also quite disconnected from data and state of an inferior > Python or pdb interaction buffer. Not much useful. > > An idea, maybe! I do not know how doable it would be: maybe Pymacs > should have some operational mode by which it starts a new thread in an > already existing program, and as such, opening a window into it. It > surely cannot install itself on the main thread then, which is often > reserved for GUI interactions and such things. Maybe threaded programs > want full control over their threads, and would squash Pymacs at the > first opportunity? Maybe a Pymacs thread would mess program > termination? Maybe this is a big can of worms, I do not know. try M-x python-dedicated for a better sleep :) Well, have some visions indeed. Some advices from you, resp. some bug reports will make it advance. Cheers, Andreas > > Fran?ois > > P.S. There are interesting and tempting problems in there, but I have so > little free time. Sigh! > From pinard at iro.umontreal.ca Tue Jan 24 04:28:27 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Mon, 23 Jan 2012 22:28:27 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F1DBF8A.7040207@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Mon, 23 Jan 2012 21:14:02 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> Message-ID: <87boptdbj8.fsf@iro.umontreal.ca> Andreas R?hler writes: > if you could manage to moan into the bug-tracker, that will be great > :) Don't get me started on bug trackers! :-) I much prefer humans to robots. But OK, I'll ponder how usable is your tracker. It better *behaves*! :-) > Existing python-mode should not disturb installed Pymacs. Does it? I do not know. I've no problem currently, because the Python mode version lags only a bit, and for tiny things without consequences. > https://bugs.launchpad.net/python-mode I've seen much worse than this tracker, could be better. Trackers are also devices favoring bad maintainer attitudes. Some of my ramblings: https://plus.google.com/110898546836957350133/posts/NLwkdraQeay > If not, next step might be a repo, keeping/installing Pymacs alongside > with our stuff. Whatever works best! > try M-x python-dedicated for a better sleep :) Wrong type argument: commandp, python-dedicated > Cheers, Keep happy! > Andreas Fran?ois :-) From andreas.roehler at online.de Tue Jan 24 07:31:57 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Tue, 24 Jan 2012 07:31:57 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87boptdbj8.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> <87boptdbj8.fsf@iro.umontreal.ca> Message-ID: <4F1E505D.7020304@online.de> Am 24.01.2012 04:28, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> if you could manage to moan into the bug-tracker, that will be great >> :) > > Don't get me started on bug trackers! :-) I much prefer humans to > robots. I'm your man! - LC :) But OK, I'll ponder how usable is your tracker. It better > *behaves*! :-) > >> Existing python-mode should not disturb installed Pymacs. Does it? > > I do not know. I've no problem currently, because the Python mode > version lags only a bit, and for tiny things without consequences. > >> https://bugs.launchpad.net/python-mode > > I've seen much worse than this tracker, could be better. Trackers are > also devices favoring bad maintainer attitudes. Some of my ramblings: > > https://plus.google.com/110898546836957350133/posts/NLwkdraQeay > "Bug trackers and other maintainer tools are not so meant to ease communications, than to give maintainers some feel they are good at processing bug reports. The original idea was to solve programming problems, but it rather quickly shifted into a starve to get rid of the report, or even the user. I observed this a lot of times." Ahh, you got me completely. https://bugs.launchpad.net/python-mode provides a kind of wellness. And indeed: it helps to forget. Thus living relaxed with all the fuss stored savely until the end of times - :) >> If not, next step might be a repo, keeping/installing Pymacs alongside >> with our stuff. > > Whatever works best! > >> try M-x python-dedicated for a better sleep :) > > Wrong type argument: commandp, python-dedicated bzr branch lp:python-mode should deliver it, afterwards a bzr pull to update Let's go on, Andreas > >> Cheers, > > Keep happy! > >> Andreas > > Fran?ois :-) > From andreas.roehler at online.de Tue Jan 24 07:51:12 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Tue, 24 Jan 2012 07:51:12 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87boptdbj8.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> <87boptdbj8.fsf@iro.umontreal.ca> Message-ID: <4F1E54E0.4070801@online.de> Am 24.01.2012 04:28, schrieb Fran?ois Pinard: > > https://plus.google.com/110898546836957350133/posts/NLwkdraQeay > Hi Fran?ois, had quite similar apprehensions when started. Changed my mind. Now use it as a kind of notebook, sometimes splitting reports into pieces still. Delivers a good reference when filtered. Relaxing and animating likewise. Cheers, Andreas From pinard at iro.umontreal.ca Tue Jan 24 16:11:13 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Tue, 24 Jan 2012 10:11:13 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F1E505D.7020304@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Tue, 24 Jan 2012 07:31:57 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> <87boptdbj8.fsf@iro.umontreal.ca> <4F1E505D.7020304@online.de> Message-ID: <87ipk1m8z2.fsf@iro.umontreal.ca> Andreas R?hler writes: > And indeed: it helps to forget. Thus living relaxed with all the fuss > stored savely [within bug trackers] until the end of times - :) Don't sleep too comfortably! I often saw bug trackers losing bugs, yet I agree that they got more solid and dependable over time, but not fully. > Now use it as a kind of notebook, sometimes splitting reports into > pieces still. Delivers a good reference when filtered. Relaxing and > animating likewise. Exactly. bug trackers are tools for *maintainers*. Whatever makes them comfortable and happy. They can refile, tag, sort, split, as much as they want. This may be their choice and sandboxes. These tools may *also* be convenient for users too, at least as a way, among others, to let them know what is (not) happening. I do understand they may be useful for everybody. As long as maintainers do not become fascist about them, I've no problem. :-) Fran?ois From andreas.roehler at online.de Tue Jan 24 18:21:51 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Tue, 24 Jan 2012 18:21:51 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87ipk1m8z2.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> <87boptdbj8.fsf@iro.umontreal.ca> <4F1E505D.7020304@online.de> <87ipk1m8z2.fsf@iro.umontreal.ca> Message-ID: <4F1EE8AF.5010802@online.de> Am 24.01.2012 16:11, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> And indeed: it helps to forget. Thus living relaxed with all the fuss >> stored savely [within bug trackers] until the end of times - :) > > Don't sleep too comfortably! I often saw bug trackers losing bugs, yet > I agree that they got more solid and dependable over time, but not fully. > >> Now use it as a kind of notebook, sometimes splitting reports into >> pieces still. Delivers a good reference when filtered. Relaxing and >> animating likewise. > > Exactly. bug trackers are tools for *maintainers*. Whatever makes them > comfortable and happy. They can refile, tag, sort, split, as much as > they want. This may be their choice and sandboxes. These tools may > *also* be convenient for users too, at least as a way, among others, to > let them know what is (not) happening. I do understand they may be > useful for everybody. As long as maintainers do not become fascist > about them, I've no problem. :-) > > Fran?ois started a Blueprint delivering the reasons for the kind of proceeding tried currently https://blueprints.launchpad.net/python-mode/+spec/pymacs Think such a Blueprint might be a good place for listing pros and cons. Using Make has it's merits too, bien sure. Andreas From pinard at iro.umontreal.ca Wed Jan 25 04:28:45 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Tue, 24 Jan 2012 22:28:45 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F1D1974.5020902@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Mon, 23 Jan 2012 09:25:24 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> Message-ID: <87r4yocvf6.fsf@iro.umontreal.ca> pinard at iro.umontreal.ca (Fran?ois Pinard) writes: > It seems that one problem you met is that Pymacs installs a Python > package, having only pymacs.py besides __init__.py, while you prefer a > single pymacs.py file. Hi Andreas, and gang. :-) This detail should be over. Pymacs now installs a single Pymacs.py file (after pre-processing it out of Pymacs.py.in), and it does not install a package anymore. I kept the capital (it is Pymacs.py instead of pymacs.py) merely so the documented API does not change at all. While doing this, I saw that the distinction between a file and a package matters at many little places in my code. python-mode has been distributing a single file, while Pymacs code was really written for a package. So, I wonder if Pymacs *ever* worked in python-mode... The commit is now on GitHub (https://github.com/pinard/Pymacs). Hopefully, no Pymacs users will complain about the disappearance of a Pymacs package. It is always possible that someone will reveal a blunt I do not see right now; if this happens, more thinking will be needed. This simplification in Pymacs should ease its usage in python-mode. Fran?ois P.S. I am a bit sad. After replacing the python-mode bundled in Ubuntu by the one bleeding within launchpad, I did *not* succeed in having it to work for me, earlier today. And my debugging abilities in Emacs are rather dusty. I have to put all of this aside for a little while, because of other duties. As Arnold S. used to say: "I'll be back!" From andreas.roehler at online.de Thu Jan 26 10:42:56 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Thu, 26 Jan 2012 10:42:56 +0100 Subject: [Python-mode] py-execute-region - was: [Merge] lp:~yagnesh/python-mode/py-shell into lp:python-mode In-Reply-To: References: Message-ID: <4F212020.4090106@online.de> Am 26.01.2012 09:43, schrieb yagnesh: > On 01/26/2012 04:45 PM, Andreas Roehler wrote: >> Hi, >> >> as `py-shell-name' will exist with some probability, don't see >> how `py-choose-shell-by-shebang' get's a chance that way. >> >> Do you experienced a related bug prior to this change? >> Would prefer to proceed with some example. >> >> Thanks contributing, >> >> Andreas > > > Hello Andreas, > > lets say I have this in my .emacs > > --------------------------------------------------- > (require 'python-mode) > (add-hook 'python-mode-hook > (lambda () > (setq py-shell-name "ipython"))) > --------------------------------------------------- > > now I open a file with shebang containing > > #!/usr/bin/env python3 > > and press C-c C-c it takes me to a python3 shell instead of ipython. Hi all, intend to change py-execute-region accepting an optional argument "execute-with-this-shell-instead-of-shebang" would replace "&optional async", as "async" is broken for years and no-one complained. Agreed? Cheers, Andreas From pinard at iro.umontreal.ca Fri Jan 27 03:27:43 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 21:27:43 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F1EE8AF.5010802@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Tue, 24 Jan 2012 18:21:51 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> <87boptdbj8.fsf@iro.umontreal.ca> <4F1E505D.7020304@online.de> <87ipk1m8z2.fsf@iro.umontreal.ca> <4F1EE8AF.5010802@online.de> Message-ID: <87liotubfk.fsf@iro.umontreal.ca> Andreas R?hler writes: > started a Blueprint delivering the reasons for the kind of proceeding > tried currently > https://blueprints.launchpad.net/python-mode/+spec/pymacs > Think such a Blueprint might be a good place for listing pros and cons. > Using Make has it's merits too, bien sure. Hello, Andreas, and gang. After a quick visit to the link above, its purpose is not clear. Is that a device you happen to like for organizing your own thoughts on the matter, and where you can later direct people when you feel useful to so? If yes : nice, good, great! Enjoy, and have a lot of fun! :-) Am I expected to follow what's in it? No problem I get an email whenever it gets edited. Otherwise, as I really do not feel like having-yet-another-thing-to-check-daily. I have far too much already. Do you expect me to share ideas in there? Do you really expect me to use Web editors for speaking to a "blueprint"? I much prefer humans. And moreover, what's wrong with Emacs, email, and this mailing list? As a grown up, you surely not need me to jump into your chosen sandbox for organizing thoughts in your place, are you? *You* do that! ;-) If you want to help me organizing my own ideas, thanks, but I can manage. Fran?ois P.S. Who hates the useless multiplication of maintainer toys, and who honestly needs a good incentive before taking the time it takes to study what each is meant to do, and how (badly) it does (not do) it... From pinard at iro.umontreal.ca Fri Jan 27 04:12:32 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 22:12:32 -0500 Subject: [Python-mode] python setup ? In-Reply-To: <49FF4917.3050502@easy-emacs.de> ("Andreas =?utf-8?Q?R=C3=B6h?= =?utf-8?Q?ler=22's?= message of "Mon, 04 May 2009 21:59:19 +0200") References: <200904280634.n3S6YctW009278@zogzog.maillard.mobi> <49F95274.4000801@easy-emacs.de> <49ff1e8a.0407560a.7f38.137e@mx.google.com> <49FF4917.3050502@easy-emacs.de> Message-ID: <87r4yldejj.fsf@iro.umontreal.ca> Andreas R?hler writes: > [...] we should let the user decide, what features to use: ipython or > not, pdbtrack or pydb, which completion, refactoring, which checks and > tests etc. As a general principle, users should have full control. However, if a user did not explicitly activate or inhibit features, python-mode should ideally check what's available and auto-configure itself while starting, in the most advantageous way possible for the user. Users should not have to explicitly turn on configuration switches to raise below some minimal configuration. The default python-mode behaviour should be on the side of the user rather than minimalism. If some use happens to not like an available feature which python-mode decide to be a desirable one, (s)he should turn it off explicitly. Just an example, by default, python-mode should have an *opinion* about the best way to auto-complete, and activate the *best* way possible, given what's has been installed besides python-mode. Of course, *best* is extremely debatable. Another example : I would consider that hideshow or highlight-indentation are desirable. Opinions may differ, and we cannot at the same time please me, you and everybody. Yet, python-mode should at least have an opinion. Not activating things, as a way to stay neutral and avoiding the expression of any opinion, does not serve the average python-mode user, who would prefer something as interesting as possible, by default, without having anything to do on the configuration side. Fran?ois From pinard at iro.umontreal.ca Fri Jan 27 04:44:05 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 22:44:05 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20100119162553.40a3f66b@freewill> (Barry Warsaw's message of "Tue, 19 Jan 2010 16:25:53 -0500") References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> Message-ID: <87mx99dd2y.fsf@iro.umontreal.ca> Barry Warsaw writes: >>How do I invoke pdbtrack from python-mode? > It's really easy. You still insert 'import pdb; pdb.set_trace()' at the spot > in your code where you want to break. Then run your code from a shell buffer. > When you hit the break point, you'll drop into pdb. pdb-track will notice the > new prompt and you'll be able to interact with it right there. You'll use pdb > commands but you'll get the nice two-screen view with code tracking. Hi, python-mode people. I quote Barry's explanation above, as an example of fruitful instructions about how to use python-mode. Looking at the mailing list archives, here and there, I read other nice advice or tricks. But it's a pity that these did not get collected into a user documentation. So my suggestions: * take the above quote and drop it *as is* within the README file (yes, the README, not in the doc/ directory, nor any fancier place). Right now, without hesitation. * whenever any usage advice is given on the list, someone with commit powers immediately copies it, as is, within the README. * do not try to devise a fancy structure or flowing text right away, the emergency right now is to give some informational meat to users, rather than a nice structure filled with lots of TBDs (to be done). The TBDs should go to the TODO file (which, by the way, is the traditional capitalisation for it), not in the README. * do not worry, structure will come very naturally, later, as material accumulates within README. Information first, structure later. * integrate the INSTALL file within README, get rid of it as a separate file. It is not worth a file as it stands right now. Let it grow within README, and give it an existence in a separate file only when it will hold enough substance to be worth its own file. Do not think "INSTALL exists so people may start without having to read README". On the contrary, manage so users will more likely peruse README. * get rid of doc/, or at least change its name. Users are mislead to think there is a documentation in there that is usable for them. Fran?ois P.S. Reading further, Barry wrote: > I owe Ken Manheimer a lifetime supply of [insert beverage] for this > beautiful hack. Sigh! If only I could have developed something so attractive that Barry did such an offer to *me*. I spoiled my life! :-) From pinard at iro.umontreal.ca Fri Jan 27 05:03:19 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 23:03:19 -0500 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> (Deniz Dogan's message of "Fri, 19 Mar 2010 12:54:08 +0100") References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> Message-ID: <87ipjxdc6w.fsf@iro.umontreal.ca> Deniz Dogan writes: > Unfortunately, that breaks yet another convention, which is that C-c > are for users and should not be bound to anything in any > external mode. Doing `C-h m' while visiting a Python file, I currently see two culprits: C-c c py-compute-indentation C-x n d py-narrow-to-defun This is important to respect the convention. The space left for users to install their own keybinding is tiny, and should be respected. For one, I have many C-c prefixes, opening into a lot of three keys commands. By the way, let me mention that Org mode has a rather original way to circumvent this convention, without breaking it. If I remember correctly, they clearly and prominently document that users should install these bindings or prefixes themselves, explaining how to do so, and providing examples. Since the user does it, and not them, they are lawful good. Users then choose bindings differently than in the examples, if they know they would clash in some way. Forcefully defining C-c in modes with the excuse that "users may redefine them if they do not like it", is breaking the convention. Fran?ois From pinard at iro.umontreal.ca Fri Jan 27 05:08:29 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 23:08:29 -0500 Subject: [Python-mode] pymacs-start-services fails In-Reply-To: <4BA93416.6060605@online.de> (Andreas Roehler's message of "Tue, 23 Mar 2010 22:35:18 +0100") References: <4BA93416.6060605@online.de> Message-ID: <87ehuldbya.fsf@iro.umontreal.ca> Andreas Roehler writes: > Pymacs-0.24-beta1 > pymacs-eval resp. `pymacs-start-services' fails > In *Pymacs*-buffer it says: > "No module named Pymacs.pymacs" > Any ideas? I do not know what was the situation at the time, but as I saw pymacs.py within python-mode as a file while usage was meant as a package, it is "normal" that it did not start. Maybe my comment is fully irrelevant. Right now, the Pymacs in the works does not use a package anymore. As I wrote to this list earlier (Andreas told me he missed the message), this should ease usage of a Pymacs integrated within python-mode. Beware that the file is now Pymacs.py, and not pymacs.py. This is to stay compatible with my previous mistakes! :-) Fran?ois From jbauer at rubic.com Fri Jan 27 05:12:06 2012 From: jbauer at rubic.com (Jeff Bauer) Date: Thu, 26 Jan 2012 22:12:06 -0600 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <87mx99dd2y.fsf@iro.umontreal.ca> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <87mx99dd2y.fsf@iro.umontreal.ca> Message-ID: <20120127041206.GA27577@waldo.rubic.com> Fran?ois, Hah! So funny for you to bring up *that* specific post from Barry. It's been sitting in my inbox as msg #1 for the past couple years. Even though I copied it to my org notes, I've always had it there. So when your email arrived, my reader threaded it back to Barry's 2-year-old post. What!? Then I read your text and it all made sense. ;-) P.S. to Barry: My upgrade to Emacs 24 via launchpad has been a totally painless non-event. Jeff "Shawn White" Bauer Rubicon, Inc. On Thu, Jan 26, 2012 at 10:44:05PM -0500, Fran?ois Pinard wrote: > Barry Warsaw writes: > > >>How do I invoke pdbtrack from python-mode? > > > It's really easy. You still insert 'import pdb; pdb.set_trace()' at the spot > > in your code where you want to break. Then run your code from a shell buffer. > > When you hit the break point, you'll drop into pdb. pdb-track will notice the > > new prompt and you'll be able to interact with it right there. You'll use pdb > > commands but you'll get the nice two-screen view with code tracking. > > Hi, python-mode people. > > I quote Barry's explanation above, as an example of fruitful > instructions about how to use python-mode. Looking at the mailing list > archives, here and there, I read other nice advice or tricks. > > But it's a pity that these did not get collected into a user > documentation. So my suggestions: > > * take the above quote and drop it *as is* within the README file (yes, > the README, not in the doc/ directory, nor any fancier place). Right > now, without hesitation. > > * whenever any usage advice is given on the list, someone with commit > powers immediately copies it, as is, within the README. > > * do not try to devise a fancy structure or flowing text right away, the > emergency right now is to give some informational meat to users, > rather than a nice structure filled with lots of TBDs (to be done). > The TBDs should go to the TODO file (which, by the way, is the > traditional capitalisation for it), not in the README. > > * do not worry, structure will come very naturally, later, as material > accumulates within README. Information first, structure later. > > * integrate the INSTALL file within README, get rid of it as a separate > file. It is not worth a file as it stands right now. Let it grow > within README, and give it an existence in a separate file only when > it will hold enough substance to be worth its own file. Do not think > "INSTALL exists so people may start without having to read README". > On the contrary, manage so users will more likely peruse README. > > * get rid of doc/, or at least change its name. Users are mislead to > think there is a documentation in there that is usable for them. > > Fran?ois > > P.S. Reading further, Barry wrote: > > > I owe Ken Manheimer a lifetime supply of [insert beverage] for this > > beautiful hack. > > Sigh! If only I could have developed something so attractive that Barry > did such an offer to *me*. I spoiled my life! :-) > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From barry at python.org Fri Jan 27 05:14:00 2012 From: barry at python.org (Barry Warsaw) Date: Thu, 26 Jan 2012 23:14:00 -0500 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <87ipjxdc6w.fsf@iro.umontreal.ca> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> <87ipjxdc6w.fsf@iro.umontreal.ca> Message-ID: <20120126231400.61a701dd@resist.wooz.org> On Jan 26, 2012, at 11:03 PM, Fran?ois Pinard wrote: >C-x n d py-narrow-to-defun Is this one a problem? Shouldn't narrow-to-defun be mode-sensitive? (Also, it doesn't sit on C-c .) -Barry From barry at python.org Fri Jan 27 05:17:55 2012 From: barry at python.org (Barry Warsaw) Date: Thu, 26 Jan 2012 23:17:55 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <87mx99dd2y.fsf@iro.umontreal.ca> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <87mx99dd2y.fsf@iro.umontreal.ca> Message-ID: <20120126231755.40cd3d4a@resist.wooz.org> On Jan 26, 2012, at 10:44 PM, Fran?ois Pinard wrote: >Sigh! If only I could have developed something so attractive that Barry >did such an offer to *me*. I spoiled my life! :-) There's still time. :) -Barry From barry at python.org Fri Jan 27 05:19:48 2012 From: barry at python.org (Barry Warsaw) Date: Thu, 26 Jan 2012 23:19:48 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20120127041206.GA27577@waldo.rubic.com> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <87mx99dd2y.fsf@iro.umontreal.ca> <20120127041206.GA27577@waldo.rubic.com> Message-ID: <20120126231948.7a086058@resist.wooz.org> On Jan 26, 2012, at 10:12 PM, Jeff Bauer wrote: >Hah! So funny for you to bring up *that* specific post from >Barry. It's been sitting in my inbox as msg #1 for the past >couple years. Even though I copied it to my org notes, I've >always had it there. So when your email arrived, my reader >threaded it back to Barry's 2-year-old post. What!? Wait. I wrote that two *freakin'* years ago?! >P.S. to Barry: My upgrade to Emacs 24 via launchpad has been >a totally painless non-event. \o/ So, who's gonna be at Pycon this year? -Barry From pinard at iro.umontreal.ca Fri Jan 27 05:28:23 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 23:28:23 -0500 Subject: [Python-mode] [Fwd: Python auto-completion without pymacs] In-Reply-To: <4BC55A75.1030702@easy-emacs.de> ("Andreas =?utf-8?Q?R=C3=B6h?= =?utf-8?Q?ler=22's?= message of "Wed, 14 Apr 2010 08:02:29 +0200") References: <4BC55A75.1030702@easy-emacs.de> Message-ID: <877h0ddb14.fsf@iro.umontreal.ca> Andreas R?hler writes: > From: Andrea Crotti > Date: 2010-04-13 07:45 > Given that I had some bad experiences with pymacs I would like to avoid > it entirely [...] I'm a bit curious about what those bad experiences have been. It's not that I want you to use Pymacs, I'm not using it much myself :-). Moreover, I could at least warn my users, and it might help python-mode maintainers deciding about what's best for python-mode users. Pymacs has some flaws, which I document in the manual when I learn about them. Some may be serious. When signals get intercepted on the Python side, the Lisp part and the Python part lose synchronization while unstacking, while they should ideally unstack synchronously. Threading on the Python side may seriously mix things if proper care is not taken. And more recently, I saw that Pymacs is useless at really inspecting the state of a running program started though python-mode. At least weaker than pdb. Completion is surely limited, would it be for this reason. I'm not saying that Pymacs should be avoided, but at least, we should try to have a clear mind about what it can and cannot do. So yes, bad experiences are worth reporting, too. :-) Fran?ois From pinard at iro.umontreal.ca Fri Jan 27 05:34:21 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 23:34:21 -0500 Subject: [Python-mode] highlight-indentation In-Reply-To: <4D77F01F.8030201@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Wed, 09 Mar 2011 22:24:47 +0100") References: <4D77F01F.8030201@online.de> Message-ID: <8739b1dar6.fsf@iro.umontreal.ca> Andreas R?hler writes: > just seeing highlight-indentation by Anton Johansson [...] It > delivers graphical bars indicating the indent-level, makes em more > impressive. Might be useful in certain circumstances. I wonder if someone (not me!) could devise some overly trickery by which the vertical bars would be thinner. I guess (without being sure) that it currently uses grey background for single space characters. One column wide is fairly thick. A light gray background make the aspect a bit less striking, but yet, it is still a bit thick. :-) Fran?ois From pinard at iro.umontreal.ca Fri Jan 27 05:44:39 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Thu, 26 Jan 2012 23:44:39 -0500 Subject: [Python-mode] python-mode.el 6.0 released In-Reply-To: <4E2B2DCE.5070905@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Sat, 23 Jul 2011 22:23:42 +0200") References: <4E2AFB76.80505@online.de> <4E2B1335.6020509@g.nevcal.com> <4E2B19F6.9070801@online.de> <4E2B28BE.8000908@g.nevcal.com> <4E2B2DCE.5070905@online.de> Message-ID: <87y5stbvpk.fsf@iro.umontreal.ca> Andreas R?hler writes: >>>> (add-to-list 'load-path "d:/somewhere") >>>> (autoload 'python-mode "python-mode" "Python Mode." t) >>> make sure python-mode.el is earlier in path than python.el >> Does add-to-list do that? > Good question. M-x describe-variable RET load-path should tell you. While I understand Andreas reply, we should not loose sight that Python users do not necessarily want to know that much about Emacs. There is a quite a long way between starting Emacs to edit Python code, and knowing about Emacs variables, discovering M-x functions like describe-variable (there are so many of these functions, and so many ways to get help), and load-path details. To develop python-mode, knowing Emacs more deeply is inescapable. To use python-mode, we should expect about nothing from user knowledge about Emacs Lisp. So, for any basic "good question", this is python-mode's README that should tell you. It should be sufficient to get fully started. Fran?ois From pinard at iro.umontreal.ca Fri Jan 27 06:23:08 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Fri, 27 Jan 2012 00:23:08 -0500 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <20120126231400.61a701dd@resist.wooz.org> (Barry Warsaw's message of "Thu, 26 Jan 2012 23:14:00 -0500") References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> <87ipjxdc6w.fsf@iro.umontreal.ca> <20120126231400.61a701dd@resist.wooz.org> Message-ID: <87fwf1btxf.fsf@iro.umontreal.ca> Barry Warsaw writes: > On Jan 26, 2012, at 11:03 PM, Fran?ois Pinard wrote: >>C-x n d py-narrow-to-defun > Is this one a problem? Shouldn't narrow-to-defun be mode-sensitive? (Also, > it doesn't sit on C-c .) Sorry, I misread! Strike this line out in my message! Fran?ois From andreas.roehler at online.de Fri Jan 27 07:33:44 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 07:33:44 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87liotubfk.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87obtu48s0.fsf@iro.umontreal.ca> <4F1DBF8A.7040207@online.de> <87boptdbj8.fsf@iro.umontreal.ca> <4F1E505D.7020304@online.de> <87ipk1m8z2.fsf@iro.umontreal.ca> <4F1EE8AF.5010802@online.de> <87liotubfk.fsf@iro.umontreal.ca> Message-ID: <4F224548.2060406@online.de> Am 27.01.2012 03:27, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> started a Blueprint delivering the reasons for the kind of proceeding >> tried currently > >> https://blueprints.launchpad.net/python-mode/+spec/pymacs > >> Think such a Blueprint might be a good place for listing pros and cons. >> Using Make has it's merits too, bien sure. > > Hello, Andreas, and gang. > Bon jour Fran?ois, > After a quick visit to the link above, its purpose is not clear. > > Is that a device you happen to like for organizing your own thoughts on > the matter, and where you can later direct people when you feel useful > to so? consider it a kind of organizer for a certain title resp. task If yes : nice, good, great! Enjoy, and have a lot of fun! :-) > > Am I expected to follow what's in it? No problem I get an email > whenever it gets edited. Otherwise, as I really do not feel like > having-yet-another-thing-to-check-daily. I have far too much already. > > Do you expect me to share ideas in there? Do you really expect me to > use Web editors for speaking to a "blueprint"? I much prefer humans. it's just a possibility, some editable notice. Always listening :) > And moreover, what's wrong with Emacs, email, and this mailing list? > Sending Mails onto the Blueprint works too > As a grown up, you surely not need me to jump into your chosen sandbox > for organizing thoughts in your place, are you? *You* do that! ;-) If > you want to help me organizing my own ideas, thanks, but I can manage. > it's rather to make public some project, discussion with results it. a kind of public reflecting. > Fran?ois > > P.S. Who hates the useless multiplication of maintainer toys, and who > honestly needs a good incentive before taking the time it takes to study > what each is meant to do, and how (badly) it does (not do) it... okay So let's come to the very issue of https://blueprints.launchpad.net/python-mode/+spec/pymacs not mentioned yet :) BTW did you see https://blueprints.launchpad.net/~fpinard Isn't that nice ;) Cheers, Andreas From andreas.roehler at online.de Fri Jan 27 07:52:15 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 07:52:15 +0100 Subject: [Python-mode] python setup ? In-Reply-To: <87r4yldejj.fsf@iro.umontreal.ca> References: <200904280634.n3S6YctW009278@zogzog.maillard.mobi> <49F95274.4000801@easy-emacs.de> <49ff1e8a.0407560a.7f38.137e@mx.google.com> <49FF4917.3050502@easy-emacs.de> <87r4yldejj.fsf@iro.umontreal.ca> Message-ID: <4F22499F.10807@online.de> Am 27.01.2012 04:12, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> [...] we should let the user decide, what features to use: ipython or >> not, pdbtrack or pydb, which completion, refactoring, which checks and >> tests etc. > > As a general principle, users should have full control. However, if a > user did not explicitly activate or inhibit features, python-mode should > ideally check what's available and auto-configure itself while starting, > in the most advantageous way possible for the user. > > Users should not have to explicitly turn on configuration switches to > raise below some minimal configuration. The default python-mode > behaviour should be on the side of the user rather than minimalism. If > some use happens to not like an available feature which python-mode > decide to be a desirable one, (s)he should turn it off explicitly. > > Just an example, by default, python-mode should have an *opinion* about > the best way to auto-complete, and activate the *best* way possible, > given what's has been installed besides python-mode. Of course, *best* > is extremely debatable. Another example : I would consider that > hideshow or highlight-indentation are desirable. Opinions may differ, > and we cannot at the same time please me, you and everybody. Yet, > python-mode should at least have an opinion. > > Not activating things, as a way to stay neutral and avoiding the > expression of any opinion, does not serve the average python-mode user, > who would prefer something as interesting as possible, by default, > without having anything to do on the configuration side. > > Fran?ois Thanks! IMO a quite perfect description of some principle to act. Think it's good to keep that somewhere, being able to refer to also for new users/developers studying python-mode stored it here for the moment: https://blueprints.launchpad.net/python-mode/+spec/features title might be to change still From andreas.roehler at online.de Fri Jan 27 07:56:00 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 07:56:00 +0100 Subject: [Python-mode] pymacs-start-services fails In-Reply-To: <87ehuldbya.fsf@iro.umontreal.ca> References: <4BA93416.6060605@online.de> <87ehuldbya.fsf@iro.umontreal.ca> Message-ID: <4F224A80.6080509@online.de> Am 27.01.2012 05:08, schrieb Fran?ois Pinard: > Andreas Roehler writes: > >> Pymacs-0.24-beta1 >> pymacs-eval resp. `pymacs-start-services' fails >> In *Pymacs*-buffer it says: >> "No module named Pymacs.pymacs" > >> Any ideas? > > I do not know what was the situation at the time, but as I saw pymacs.py > within python-mode as a file while usage was meant as a package, it is > "normal" that it did not start. Maybe my comment is fully irrelevant. > > Right now, the Pymacs in the works does not use a package anymore. As I > wrote to this list earlier (Andreas told me he missed the message), this > should ease usage of a Pymacs integrated within python-mode. Beware > that the file is now Pymacs.py, and not pymacs.py. This is to stay > compatible with my previous mistakes! :-) > > Fran?ois should this error occur, please make a bug report. we have not such a report at the moment Cheers, Andreas From andreas.roehler at online.de Fri Jan 27 08:23:55 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 08:23:55 +0100 Subject: [Python-mode] python-mode.el 6.0 released In-Reply-To: <87y5stbvpk.fsf@iro.umontreal.ca> References: <4E2AFB76.80505@online.de> <4E2B1335.6020509@g.nevcal.com> <4E2B19F6.9070801@online.de> <4E2B28BE.8000908@g.nevcal.com> <4E2B2DCE.5070905@online.de> <87y5stbvpk.fsf@iro.umontreal.ca> Message-ID: <4F22510B.9050904@online.de> Am 27.01.2012 05:44, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >>>>> (add-to-list 'load-path "d:/somewhere") >>>>> (autoload 'python-mode "python-mode" "Python Mode." t) > >>>> make sure python-mode.el is earlier in path than python.el > >>> Does add-to-list do that? > >> Good question. M-x describe-variable RET load-path should tell you. > > While I understand Andreas reply, we should not loose sight that Python > users do not necessarily want to know that much about Emacs. There is a > quite a long way between starting Emacs to edit Python code, and knowing > about Emacs variables, discovering M-x functions like describe-variable > (there are so many of these functions, and so many ways to get help), > and load-path details. > > To develop python-mode, knowing Emacs more deeply is inescapable. To use > python-mode, we should expect about nothing from user knowledge about > Emacs Lisp. > > So, for any basic "good question", this is python-mode's README that > should tell you. It should be sufficient to get fully started. > > Fran?ois > will add that onto https://blueprints.launchpad.net/python-mode/+spec/features Thanks, Andreas From andreas.roehler at online.de Fri Jan 27 08:28:56 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 08:28:56 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <87ipjxdc6w.fsf@iro.umontreal.ca> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> <87ipjxdc6w.fsf@iro.umontreal.ca> Message-ID: <4F225238.3080403@online.de> Am 27.01.2012 05:03, schrieb Fran?ois Pinard: > Deniz Dogan writes: > >> Unfortunately, that breaks yet another convention, which is that C-c >> are for users and should not be bound to anything in any >> external mode. > > Doing `C-h m' while visiting a Python file, I currently see two > culprits: > > C-c c py-compute-indentation sorry, that's my personal setting slipped in. will remove it Andreas From andreas.roehler at online.de Fri Jan 27 09:04:52 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 09:04:52 +0100 Subject: [Python-mode] highlight-indentation In-Reply-To: <8739b1dar6.fsf@iro.umontreal.ca> References: <4D77F01F.8030201@online.de> <8739b1dar6.fsf@iro.umontreal.ca> Message-ID: <4F225AA4.8080602@online.de> Am 27.01.2012 05:34, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> just seeing highlight-indentation by Anton Johansson [...] It >> delivers graphical bars indicating the indent-level, makes em more >> impressive. Might be useful in certain circumstances. > > I wonder if someone (not me!) could devise some overly trickery by which > the vertical bars would be thinner. I guess (without being sure) that > it currently uses grey background for single space characters. One > column wide is fairly thick. A light gray background make the aspect a > bit less striking, but yet, it is still a bit thick. :-) > > Fran?ois hmm, read your mail as pertaining to M-x column-marker-1 etc. (?) Andreas From andreas.roehler at online.de Fri Jan 27 09:45:42 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 27 Jan 2012 09:45:42 +0100 Subject: [Python-mode] [Fwd: Python auto-completion without pymacs] In-Reply-To: <877h0ddb14.fsf@iro.umontreal.ca> References: <4BC55A75.1030702@easy-emacs.de> <877h0ddb14.fsf@iro.umontreal.ca> Message-ID: <4F226436.3050000@online.de> Am 27.01.2012 05:28, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> From: Andrea Crotti >> Date: 2010-04-13 07:45 > >> Given that I had some bad experiences with pymacs I would like to avoid >> it entirely [...] > > I'm a bit curious about what those bad experiences have been. It's not > that I want you to use Pymacs, I'm not using it much myself :-). > Moreover, I could at least warn my users, and it might help python-mode > maintainers deciding about what's best for python-mode users. > > Pymacs has some flaws, which I document in the manual when I learn about > them. Some may be serious. When signals get intercepted on the Python > side, the Lisp part and the Python part lose synchronization while > unstacking, while they should ideally unstack synchronously. Threading > on the Python side may seriously mix things if proper care is not taken. > > And more recently, I saw that Pymacs is useless at really inspecting the > state of a running program started though python-mode. At least weaker > than pdb. Completion is surely limited, would it be for this reason. > > I'm not saying that Pymacs should be avoided, but at least, we should > try to have a clear mind about what it can and cannot do. So yes, bad > experiences are worth reporting, too. :-) > > Fran?ois Hi Fran?ois, appreciate it that much seeing you step into. Will also preserve that as an example in various respects. https://blueprints.launchpad.net/python-mode/+spec/pymacs-issues Cheers From andreas.roehler at online.de Fri Jan 27 10:21:02 2012 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 27 Jan 2012 10:21:02 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87r4yocvf6.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87r4yocvf6.fsf@iro.umontreal.ca> Message-ID: <4F226C7E.3020407@online.de> Am 25.01.2012 04:28, schrieb Fran?ois Pinard: > pinard at iro.umontreal.ca (Fran?ois Pinard) writes: > >> It seems that one problem you met is that Pymacs installs a Python >> package, having only pymacs.py besides __init__.py, while you prefer a >> single pymacs.py file. > > Hi Andreas, and gang. :-) > > This detail should be over. Pymacs now installs a single Pymacs.py file > (after pre-processing it out of Pymacs.py.in), and it does not install a > package anymore. I kept the capital (it is Pymacs.py instead of > pymacs.py) merely so the documented API does not change at all. > > While doing this, I saw that the distinction between a file and a > package matters at many little places in my code. python-mode has been > distributing a single file, while Pymacs code was really written for a > package. So, I wonder if Pymacs *ever* worked in python-mode... > > The commit is now on GitHub (https://github.com/pinard/Pymacs). > Hopefully, no Pymacs users will complain about the disappearance of a > Pymacs package. It is always possible that someone will reveal a blunt > I do not see right now; if this happens, more thinking will be needed. > > This simplification in Pymacs should ease its usage in python-mode. > > Fran?ois > > P.S. I am a bit sad. After replacing the python-mode bundled in Ubuntu > by the one bleeding within launchpad, I did *not* succeed in having it > to work for me, earlier today. And my debugging abilities in Emacs are > rather dusty. all I need is the output of M-x report-emacs-bug, maybe some example code, and, hmm, maybe an entry into the tracker with a nice new number? BTW if you may open an own branch at launchpad, that might be a major help. We could play with that lp-forked Pymacs then without any risk. OTOH could also upload a branch at your repo, if you prefer that. At third possibility is https://github.com/pdee/pdee Cheers, Andreas Cheers, Andreas I have to put all of this aside for a little while, > because of other duties. As Arnold S. used to say: "I'll be back!" > From pinard at iro.umontreal.ca Sat Jan 28 05:19:12 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Fri, 27 Jan 2012 23:19:12 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <20120127041206.GA27577@waldo.rubic.com> (Jeff Bauer's message of "Thu, 26 Jan 2012 22:12:06 -0600") References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <87mx99dd2y.fsf@iro.umontreal.ca> <20120127041206.GA27577@waldo.rubic.com> Message-ID: <87y5ssa27z.fsf@iro.umontreal.ca> Jeff Bauer writes: > Hah! So funny for you to bring up *that* specific post from Barry. :-) > So when your email arrived, my reader threaded it back to Barry's > 2-year-old post. Old email, that's always fun! Soon after Guido announced his first release of Python, a long long time ago, I tried it. At the time, I was trying everything :-). And besides, I was already prejudiced towards Guido because of his competent implication as a maintainer of the Audio/Sound FAQ (if I remember correctly). We corresponded for a little while on a friendly tone. I did not stay with Python for long, the window system coming with it was not as usable as I initially hoped. Life is such that I forgot the whole matter for about nine or ten years, maybe. Then, Han-Wen (from the Lilypond fame) convinced me to give Python a good look. I guess it was Python 1.5.2 at the time, which I found very worth learning and using; no trace anymore of a window system or Emacs emulator to distract me from the language. Cleaning around, I found an old letter from Guido, written at the time of my initial tries, containing many interesting comments. So I replied specifically to these comments, and Guido replied to my reply, and we pursued the conversation exactly as if it has been from yesterday! :-) It was kind of surrealist, naive, and fun! Fran?ois From barry at python.org Sat Jan 28 18:30:37 2012 From: barry at python.org (Barry Warsaw) Date: Sat, 28 Jan 2012 12:30:37 -0500 Subject: [Python-mode] making stack traces clickable in gud.el pdb output. In-Reply-To: <87y5ssa27z.fsf@iro.umontreal.ca> References: <20100119092834.7243d840@freewill> <20100119162553.40a3f66b@freewill> <87mx99dd2y.fsf@iro.umontreal.ca> <20120127041206.GA27577@waldo.rubic.com> <87y5ssa27z.fsf@iro.umontreal.ca> Message-ID: <20120128123037.0b8c388f@resist.wooz.org> On Jan 27, 2012, at 11:19 PM, Fran?ois Pinard wrote: >Soon after Guido announced his first release of Python, a long long time >ago, I tried it. At the time, I was trying everything :-). And >besides, I was already prejudiced towards Guido because of his competent >implication as a maintainer of the Audio/Sound FAQ (if I remember >correctly). We corresponded for a little while on a friendly tone. I >did not stay with Python for long, the window system coming with it was >not as usable as I initially hoped. Life is such that I forgot the >whole matter for about nine or ten years, maybe. I remember when comp.lang.python was created. Sure, I'm a Monty Python fan, but the first (seems like) several months of posts were just about the comedy team and had very little to do with a new language. So I ignored it, until about 1994. >Then, Han-Wen (from the Lilypond fame) convinced me to give Python a >good look. I guess it was Python 1.5.2 at the time, which I found very >worth learning and using; no trace anymore of a window system or Emacs >emulator to distract me from the language. Cleaning around, I found an >old letter from Guido, written at the time of my initial tries, >containing many interesting comments. So I replied specifically to >these comments, and Guido replied to my reply, and we pursued the >conversation exactly as if it has been from yesterday! :-) It was kind >of surrealist, naive, and fun! How cool! -Barry From lpeng564 at gmail.com Sat Jan 28 18:30:06 2012 From: lpeng564 at gmail.com (lpeng564 at gmail.com) Date: Sun, 29 Jan 2012 01:30:06 +0800 Subject: [Python-mode] lpeng564@gmail.com Message-ID: <478D08AD-70A2-462D-A0B3-D9507B30A5B7@gmail.com> Re: lpeng564 at gmail.com Jim Lin From pinard at iro.umontreal.ca Sun Jan 29 03:28:26 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Sat, 28 Jan 2012 21:28:26 -0500 Subject: [Python-mode] hide-show mode In-Reply-To: <4EE11753.8080005@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Thu, 08 Dec 2011 21:00:19 +0100") References: <4EE05FE7.1030700@online.de> <20111208075503.13350cac@limelight.wooz.org> <4EE11753.8080005@online.de> Message-ID: <8739az8col.fsf@iro.umontreal.ca> Andreas R?hler writes: > Introduced two variables > `py-outline-minor-mode-p' > `py-hide-show-minor-mode-p' > which are nil by default, so user shouldn't notice it > without deliberate setting. What is best for the average user? Not noticing the capabilities, or enjoying them? The default should be set according to what is best for the average user. So I take that you consider the average user should rather not be aware of these capabilities. > Hope it's okay for you Did you update README? That file should speak about capabilities and elementary configuration. It should be updated synchronously while capabilities are added or changed. I understand it cannot be written all at once. So, let's have it written progressively. I see this as the most fruitful way to eventually get a useful README. Currently, the documentation of python-mode is severely lagging, really, so aggressive habits should be set to repair that. Fran?ois P.S. Sending users for fishing in the Emacs Lisp sources is not an alternative for some documentation. Python users are not Emacs Lisp people, and we should not push them into becoming Emacs Lisp people. From pinard at iro.umontreal.ca Sun Jan 29 04:24:53 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Sat, 28 Jan 2012 22:24:53 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F1D1974.5020902@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Mon, 23 Jan 2012 09:25:24 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> Message-ID: <87y5sr6vi2.fsf@iro.umontreal.ca> Andreas R?hler writes: > If we provide the next Python-mode/Pymacs release using Make as Pymacs > does, the top directory should contain only the minimal requiring, > i.e, INSTALL, README etc. Hi, Andreas, and gang. Recently, I noticed that pymacs.el within python-mode (should be Pymacs.el from now on), has a small local modification. When Emacs launches the Python helper, it first does: " sys.path.insert(1, os.getenv('PYMACS_INSTALL_DIR'));" Let me comment a bit about this change: * Nowhere in python-mode README nor INSTALL, this PYMACS_INSTALL_DIR environment variable is presented nor explained, while it really should. Average Python mode users are unlikely to guess they have to set this environment variable prior to calling Emacs. * The change addresses a need that python-mode has and which Pymacs currently does not offer, which is the need of use it without prior installation. Don't shudder, I'm surely not going to ask you to go to GitHub and file a report about this. If I needed it, I'd do it myself rather than ask others to do it in my place -- you know me! :-) * It would be comfortable that python-mode could work with the minimum setup possible. Granted that Pymacs is not the easiest thing to package, especially since the advent of Python 3. Yet, if we could avoid the formal installation step, it would be nice. * I first thought about yet another Emacs variable to tell where exactly sits Pymacs.py, but this is not a good idea. If Emacs is not able to find Pymacs.py, other Python modules written by users would also be unable to import from Pymacs. It would be broken, just at a later stage. * So, if Pymacs.py is not installed or not available in the regular Python search path, it better be somewhere along the pymacs-load-path list. So my idea would be to launch the Pymacs helper from any Pymacs.py found in a directory listed in pymacs-load-path. If none found, then it would fall back on looking elsewhere in the system. Does it sound reasonable? Does someone see a flaw in this? Have a nice evening, everybody. Fran?ois P.S. A few more points, maybe, conveying personal opinions: * If python-mode distributes packages copied from external sources (Pymacs in this example, there are a few others), it should pay attention at keeping its copies reasonably up-to-date. Otherwise confusion, then frustration will eventually develop. * Observed flaws or developed corrections for packages included in python-mode from external source should be duly reported upstream. The GPL applies of course, one may play by the law (I recently read python-mode archives, and saw such games acted by David Love, which were not always tasteful). My point is that symmetrical collaboration is more polite, and likely more fruitful in the long run. From andreas.roehler at online.de Sun Jan 29 09:03:51 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 29 Jan 2012 09:03:51 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87y5sr6vi2.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87y5sr6vi2.fsf@iro.umontreal.ca> Message-ID: <4F24FD67.9080405@online.de> Am 29.01.2012 04:24, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> If we provide the next Python-mode/Pymacs release using Make as Pymacs >> does, the top directory should contain only the minimal requiring, >> i.e, INSTALL, README etc. > > Hi, Andreas, and gang. > > Recently, I noticed that pymacs.el within python-mode (should be > Pymacs.el from now on), has a small local modification. When Emacs > launches the Python helper, it first does: > > " sys.path.insert(1, os.getenv('PYMACS_INSTALL_DIR'));" > > Let me comment a bit about this change: > > * Nowhere in python-mode README nor INSTALL, this PYMACS_INSTALL_DIR > environment variable is presented nor explained, while it really > should. Average Python mode users are unlikely to guess they have to > set this environment variable prior to calling Emacs. > > * The change addresses a need that python-mode has and which Pymacs > currently does not offer, which is the need of use it without prior > installation. Don't shudder, I'm surely not going to ask you to go to > GitHub and file a report about this. If I needed it, I'd do it myself > rather than ask others to do it in my place -- you know me! :-) > > * It would be comfortable that python-mode could work with the minimum > setup possible. Granted that Pymacs is not the easiest thing to > package, especially since the advent of Python 3. Yet, if we could > avoid the formal installation step, it would be nice. > > * I first thought about yet another Emacs variable to tell where > exactly sits Pymacs.py, but this is not a good idea. If Emacs is > not able to find Pymacs.py, other Python modules written by users > would also be unable to import from Pymacs. It would be broken, > just at a later stage. > > * So, if Pymacs.py is not installed or not available in the regular > Python search path, it better be somewhere along the > pymacs-load-path list. So my idea would be to launch the Pymacs > helper from any Pymacs.py found in a directory listed in > pymacs-load-path. If none found, then it would fall back on looking > elsewhere in the system. Does it sound reasonable? Does someone > see a flaw in this? > > Have a nice evening, everybody. > > Fran?ois > > P.S. A few more points, maybe, conveying personal opinions: > > * If python-mode distributes packages copied from external sources > (Pymacs in this example, there are a few others), it should pay > attention at keeping its copies reasonably up-to-date. Otherwise > confusion, then frustration will eventually develop. > > * Observed flaws or developed corrections for packages included in > python-mode from external source should be duly reported upstream. > The GPL applies of course, one may play by the law (I recently read > python-mode archives, and saw such games acted by David Love, which > were not always tasteful). My point is that symmetrical collaboration > is more polite, and likely more fruitful in the long run. Hi Fran?ois, think that's our understanding too. Should something in the past didn't happen that way, assume rather a lack of force than a lack of will. Remains the question if a README is the suitable place for storing that kind of info. See you did it at Pymacs and certainly thats a possibility. Indeed we are severely behind writing the info. Sorry for that. Exists a Milestone already, 6.1.1 should deliver it - maybe already 6.1? May you open your own branch forked from trunk at lp? Could merge than all Pymacs diffs easily. Cheers, Andreas From andreas.roehler at online.de Sun Jan 29 09:39:27 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 29 Jan 2012 09:39:27 +0100 Subject: [Python-mode] hide-show mode In-Reply-To: <8739az8col.fsf@iro.umontreal.ca> References: <4EE05FE7.1030700@online.de> <20111208075503.13350cac@limelight.wooz.org> <4EE11753.8080005@online.de> <8739az8col.fsf@iro.umontreal.ca> Message-ID: <4F2505BF.3030008@online.de> Am 29.01.2012 03:28, schrieb Fran?ois Pinard: > Andreas R?hler writes: > >> Introduced two variables > >> `py-outline-minor-mode-p' >> `py-hide-show-minor-mode-p' > >> which are nil by default, so user shouldn't notice it >> without deliberate setting. > > What is best for the average user? Not noticing the capabilities, or > enjoying them? The default should be set according to what is best for > the average user. > > So I take that you consider the average user should rather not be aware > of these capabilities. Oh, oh, so what kind of punishment you have prepared? :) outline and hide-show mode are common Emacs features and will work with python-mode out-of-the-box. The question here is, if it should be switched on by default. Read "notice" here as "being activated, thus get noticed" Well, for novices, if these features are on, using some key per chance without knowing what happens, that may turn nasty. Therefor it's not delivered switched-on by default, that has being the reflection. > >> Hope it's okay for you > > Did you update README? That file should speak about capabilities and > elementary configuration. It should be updated synchronously while > capabilities are added or changed. > > I understand it cannot be written all at once. So, let's have it > written progressively. I see this as the most fruitful way to > eventually get a useful README. Currently, the documentation of > python-mode is severely lagging, really, so aggressive habits should be > set to repair that. > > Fran?ois > > P.S. Sending users for fishing in the Emacs Lisp sources is not an > alternative for some documentation. Python users are not Emacs Lisp > people, and we should not push them into becoming Emacs Lisp people. Agreed. Will do what I can, Sunday, Monday, Tuesday, Wednesday, Donnerstag... - the day of donar :) Cheers, Andreas From pinard at iro.umontreal.ca Sun Jan 29 15:24:25 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Sun, 29 Jan 2012 09:24:25 -0500 Subject: [Python-mode] hide-show mode In-Reply-To: <4F2505BF.3030008@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Sun, 29 Jan 2012 09:39:27 +0100") References: <4EE05FE7.1030700@online.de> <20111208075503.13350cac@limelight.wooz.org> <4EE11753.8080005@online.de> <8739az8col.fsf@iro.umontreal.ca> <4F2505BF.3030008@online.de> Message-ID: <87k44a8u3q.fsf@iro.umontreal.ca> Andreas R?hler writes: > Oh, oh, so what kind of punishment you have prepared? :) Me preparing punishment? Not my kind :-). My poor knowledge of English makes me miss the meaning of the above sentence, but as it is ended with a smiley, I presume it is a friendly tease! > outline and hide-show mode are common Emacs features and will work > with python-mode out-of-the-box. They will surely not, if users have to explicitly turn them on. You probably meant: these minor modes would work, if turned on. > The question here is, if it should be switched on by default. Read > "notice" here as "being activated, thus get noticed" Well, for > novices, if these features are on, using some key per chance without > knowing what happens, that may turn nasty. Therefor it's not > delivered switched-on by default, that has being the reflection. OK. If this is really the reason, it is a good reason. As I wrote in some earlier message, python-mode has not only the right to, but the duty of an "opinion" about what is best for average Python users, and should deliver itself defaulted according to this opinion. >> Did you update README? That file should speak about capabilities and >> elementary configuration. > Agreed. Will do what I can, Sunday, Monday, Tuesday, Wednesday, > Donnerstag... - the day of donar :) The importance of giving some usable documentation for python-mode should not be underestimated. I see it as a top priority in the case here, because it is severely lagging. And when I say "lagging", this is a polite euphemism, "lacking" would me a more appropriate description. That importance goes above that of all the Blueprints altogether, you know :-). Oh, no doubt it is a good thing to have self-aimed internal documentation meant for planning, but if we take even a moderate distance with the python-mode project and look at its current state, the priority is clearly user documentation, not maintainer documentation. README and INSTALL are very sub-minimal currently. Only once python-mode has a least minimal documentation, resume in parallel user and maintainer documentation, and try to never lose sight again of the users in the process. Make it a principle: "Users first!" :-) Fran?ois From andreas.roehler at online.de Sun Jan 29 16:39:13 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 29 Jan 2012 16:39:13 +0100 Subject: [Python-mode] hide-show mode In-Reply-To: <87k44a8u3q.fsf@iro.umontreal.ca> References: <4EE05FE7.1030700@online.de> <20111208075503.13350cac@limelight.wooz.org> <4EE11753.8080005@online.de> <8739az8col.fsf@iro.umontreal.ca> <4F2505BF.3030008@online.de> <87k44a8u3q.fsf@iro.umontreal.ca> Message-ID: <4F256821.2050406@online.de> Make it a principle: "Users first!" :-) > > Fran?ois > > just my opinion. So let's proceed. BTW in doc there is a commands list. Might it be of some use already? Cheers, Andreas From pinard at iro.umontreal.ca Sun Jan 29 19:19:36 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Sun, 29 Jan 2012 13:19:36 -0500 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F24FD67.9080405@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Sun, 29 Jan 2012 09:03:51 +0100") References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87y5sr6vi2.fsf@iro.umontreal.ca> <4F24FD67.9080405@online.de> Message-ID: <87fwey8j7r.fsf@iro.umontreal.ca> Andreas R?hler writes: > Am 29.01.2012 04:24, schrieb Fran?ois Pinard: >> * README nor INSTALL should tell about PYMACS_INSTALL_DIR >> * The change addresses a need which Pymacs does not offer >> * python-mode should work with the minimum setup possible >> * python-mode should pay attention at keeping its copies up-to-date >> * Observed flaws should be duly reported upstream > think that's our understanding too. Should something in the past > didn't happen that way, assume rather a lack of force than a lack of > will. Yes, this is what I assume. (Same for user documentation.) Yet we have to speak out about such things, because laziness being what it is (I do know what laziness is!), those accidental misses progressively transform into habits, habits into rights, and rights into principles. We have to stay careful all along, and discuss methodology problems early -- as long, of course, as discussions do not suck up the left bits of energy! > Remains the question if a README is the suitable place for storing > that kind of info. In the current state of affairs with python-mode, yes, clearly, undoubtedly. > See you did it at Pymacs and certainly thats a possibility. Pymacs documentation is not in README, it is a reStructured Text formatted manual (the pre-processor has its own separate manual). But when Pymacs started and had nothing else, yes, it was all in README. README is the traditional unavoidable file in a distribution, where users seek for installation instructions and user documentation (or at least, pointers to where it sits, when not included). > Indeed we are severely behind writing the info. Sorry for that. > Exists a Milestone already, 6.1.1 should deliver it - maybe already > 6.1? Making Milestones, Blueprints, Gantt charts about it is not effective. Fill in the README details *right now*, when you happen to stumble on them. When you see yourself thinking "Hey, I'll add this information later into the Great Documentation I'm planning to have", slap yourself! :-) Rather *immediately* dump the information, all raw, all unformatted, into README. Do not even try to be proud of it, that would come later. For now, just pour information in it at any opportunity. > May you open your own branch forked from trunk at lp? Could merge > than all Pymacs diffs easily. Hey, let's move python-mode over to GitHub instead :-) And besides, if people really think it is hopeless to ever get python-mode integrated into Emacs, is there much remaining reason left, sticking with Bazaar? Keep happy! Fran?ois P.S. Behind the above tease, I hope you see my point: maintainers should get away from this attitude of always attempting to pull all users (or other maintainers) in their own playground. This is one of the aspects I hate about trackers and other maintainer toys. While it's comfortable for me to get a mere "pull request" on GitHub, I'd never try to force my users into it, as it might not be comfortable for them. My comfort is not *more worth* than theirs. From pinard at iro.umontreal.ca Sun Jan 29 19:40:47 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Sun, 29 Jan 2012 13:40:47 -0500 Subject: [Python-mode] hide-show mode In-Reply-To: <4F256821.2050406@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Sun, 29 Jan 2012 16:39:13 +0100") References: <4EE05FE7.1030700@online.de> <20111208075503.13350cac@limelight.wooz.org> <4EE11753.8080005@online.de> <8739az8col.fsf@iro.umontreal.ca> <4F2505BF.3030008@online.de> <87k44a8u3q.fsf@iro.umontreal.ca> <4F256821.2050406@online.de> Message-ID: <878vkq8i8g.fsf@iro.umontreal.ca> Andreas R?hler writes: > Make it a principle: "Users first!" :-) just my opinion. So let's > proceed. Of course! > BTW in doc there is a commands list. Might it be of some use already? As doc/ stands, it is not much different from the Emacs Lisp sources from which we would have subtracted Emacs Lisp. It's much better than not having sources at all, but it's not essentially better than the sources themselves, so it does not add value to the distribution. Unless I miss something, doc/ could almost go away. I use `C-h m' or `C-h b' in activated Python mode to get the key bindings, you likely do it this way also. So one sentence in README telling how to do `C-h m' or `C-h b' could likely replace the interesting part of doc/, and maybe more useful too. That's not good documentation yet, but that's a start. I doubt average Python users, not already familiar with Emacs Lisp, could manage their way into doc/, but I may well be wrong on that! Fran?ois From R.M.Everson at exeter.ac.uk Sun Jan 29 21:03:09 2012 From: R.M.Everson at exeter.ac.uk (Richard Everson) Date: Sun, 29 Jan 2012 20:03:09 +0000 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <4F24FD67.9080405@online.de> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87y5sr6vi2.fsf@iro.umontreal.ca> <4F24FD67.9080405@online.de> Message-ID: On 29 Jan 2012, at 08:03, Andreas R?hler wrote: > Am 29.01.2012 04:24, schrieb Fran?ois Pinard: >> Andreas R?hler writes: >> >>> If we provide the next Python-mode/Pymacs release using Make as Pymacs >>> does, the top directory should contain only the minimal requiring, >>> i.e, INSTALL, README etc. >> >> Hi, Andreas, and gang. >> >> Recently, I noticed that pymacs.el within python-mode (should be >> Pymacs.el from now on), has a small local modification. When Emacs >> launches the Python helper, it first does: >> >> " sys.path.insert(1, os.getenv('PYMACS_INSTALL_DIR'));" >> >> Let me comment a bit about this change: >> >> * Nowhere in python-mode README nor INSTALL, this PYMACS_INSTALL_DIR >> environment variable is presented nor explained, while it really >> should. Average Python mode users are unlikely to guess they have to >> set this environment variable prior to calling Emacs. Hi, This was my ugly hack to enable Python to find Pymacs when Pymacs is distributed with python-mode.el and is therefore not on sys.path. There's nothing about it in README or INSTALL because I think it's purely local to the python-mode/pymacs interaction and the general user shouldn't need to know or do anything about it: that environment variable is set by python-mode.el. On the other hand, it would be *much* better to use the distributed, current version of Pymacs, but it's not clear to me how to achieve that if Pymacs is not installed somewhere on the standard sys.path. Best, Richard. From andreas.roehler at online.de Sun Jan 29 21:33:59 2012 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 29 Jan 2012 21:33:59 +0100 Subject: [Python-mode] Pymacs runs from python-mode In-Reply-To: <87fwey8j7r.fsf@iro.umontreal.ca> References: <4EA9B155.7070404@online.de> <4EAA9E83.8090500@iro.umontreal.ca> <4EAABC3E.4070202@online.de> <20111028103750.3e8bf78d@limelight.wooz.org> <4EAAC4C4.5070301@online.de> <87hazn9g4d.fsf@iro.umontreal.ca> <4F1D1974.5020902@online.de> <87y5sr6vi2.fsf@iro.umontreal.ca> <4F24FD67.9080405@online.de> <87fwey8j7r.fsf@iro.umontreal.ca> Message-ID: <4F25AD37.2060106@online.de> [ ... ] >> May you open your own branch forked from trunk at lp? Could merge >> than all Pymacs diffs easily. > > Hey, let's move python-mode over to GitHub instead :-) it's mirrored here: https://github.com/pdee/pdee/tree/master/python-modes/python-mode-el Should you make a branch, Pymacs stuff shaped as you want, I can merge from there. Andreas [ ... ] From lpeng564 at gmail.com Mon Jan 30 15:39:46 2012 From: lpeng564 at gmail.com (lpeng564 at gmail.com) Date: Mon, 30 Jan 2012 22:39:46 +0800 Subject: [Python-mode] Python-mode Digest, Vol 91, Issue 17 In-Reply-To: References: Message-ID: root:alpine ? Jan 30, 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: hide-show mode ( Fran?ois Pinard) > 2. Re: hide-show mode (Andreas R?hler) > 3. Re: Pymacs runs from python-mode ( Fran?ois Pinard) > 4. Re: hide-show mode ( Fran?ois Pinard) > 5. Re: Pymacs runs from python-mode (Richard Everson) > 6. Re: Pymacs runs from python-mode (Andreas R?hler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 29 Jan 2012 09:24:25 -0500 > From: pinard at iro.umontreal.ca ( Fran?ois Pinard) > To: Andreas R?hler > Cc: python-mode at python.org > Subject: Re: [Python-mode] hide-show mode > Message-ID: <87k44a8u3q.fsf at iro.umontreal.ca> > Content-Type: text/plain; charset=utf-8 > > Andreas R?hler writes: > >> Oh, oh, so what kind of punishment you have prepared? :) > > Me preparing punishment? Not my kind :-). My poor knowledge of English > makes me miss the meaning of the above sentence, but as it is ended with > a smiley, I presume it is a friendly tease! > >> outline and hide-show mode are common Emacs features and will work >> with python-mode out-of-the-box. > > They will surely not, if users have to explicitly turn them on. You > probably meant: these minor modes would work, if turned on. > >> The question here is, if it should be switched on by default. Read >> "notice" here as "being activated, thus get noticed" Well, for >> novices, if these features are on, using some key per chance without >> knowing what happens, that may turn nasty. Therefor it's not >> delivered switched-on by default, that has being the reflection. > > OK. If this is really the reason, it is a good reason. As I wrote in > some earlier message, python-mode has not only the right to, but the > duty of an "opinion" about what is best for average Python users, and > should deliver itself defaulted according to this opinion. > >>> Did you update README? That file should speak about capabilities and >>> elementary configuration. > >> Agreed. Will do what I can, Sunday, Monday, Tuesday, Wednesday, >> Donnerstag... - the day of donar :) > > The importance of giving some usable documentation for python-mode > should not be underestimated. I see it as a top priority in the case > here, because it is severely lagging. And when I say "lagging", this is > a polite euphemism, "lacking" would me a more appropriate description. > > That importance goes above that of all the Blueprints altogether, you > know :-). Oh, no doubt it is a good thing to have self-aimed internal > documentation meant for planning, but if we take even a moderate > distance with the python-mode project and look at its current state, the > priority is clearly user documentation, not maintainer documentation. > > README and INSTALL are very sub-minimal currently. Only once > python-mode has a least minimal documentation, resume in parallel user > and maintainer documentation, and try to never lose sight again of the > users in the process. Make it a principle: "Users first!" :-) > > Fran?ois > > > > ------------------------------ > > Message: 2 > Date: Sun, 29 Jan 2012 16:39:13 +0100 > From: Andreas R?hler > To: Fran?ois Pinard > Cc: python-mode at python.org > Subject: Re: [Python-mode] hide-show mode > Message-ID: <4F256821.2050406 at online.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Make it a principle: "Users first!" :-) >> >> Fran?ois >> >> > > just my opinion. So let's proceed. > BTW in doc there is a commands list. > Might it be of some use already? > > Cheers, > > Andreas > > > ------------------------------ > > Message: 3 > Date: Sun, 29 Jan 2012 13:19:36 -0500 > From: pinard at iro.umontreal.ca ( Fran?ois Pinard) > To: pymacs-devel at googlegroups.com > Cc: python-mode at python.org > Subject: Re: [Python-mode] Pymacs runs from python-mode > Message-ID: <87fwey8j7r.fsf at iro.umontreal.ca> > Content-Type: text/plain; charset=utf-8 > > Andreas R?hler writes: >> Am 29.01.2012 04:24, schrieb Fran?ois Pinard: > >>> * README nor INSTALL should tell about PYMACS_INSTALL_DIR >>> * The change addresses a need which Pymacs does not offer >>> * python-mode should work with the minimum setup possible >>> * python-mode should pay attention at keeping its copies up-to-date >>> * Observed flaws should be duly reported upstream > >> think that's our understanding too. Should something in the past >> didn't happen that way, assume rather a lack of force than a lack of >> will. > > Yes, this is what I assume. (Same for user documentation.) Yet we have > to speak out about such things, because laziness being what it is (I do > know what laziness is!), those accidental misses progressively transform > into habits, habits into rights, and rights into principles. We have to > stay careful all along, and discuss methodology problems early -- as > long, of course, as discussions do not suck up the left bits of energy! > >> Remains the question if a README is the suitable place for storing >> that kind of info. > > In the current state of affairs with python-mode, yes, clearly, > undoubtedly. > >> See you did it at Pymacs and certainly thats a possibility. > > Pymacs documentation is not in README, it is a reStructured Text > formatted manual (the pre-processor has its own separate manual). But > when Pymacs started and had nothing else, yes, it was all in README. > README is the traditional unavoidable file in a distribution, where > users seek for installation instructions and user documentation (or at > least, pointers to where it sits, when not included). > >> Indeed we are severely behind writing the info. Sorry for that. >> Exists a Milestone already, 6.1.1 should deliver it - maybe already >> 6.1? > > Making Milestones, Blueprints, Gantt charts about it is not effective. > Fill in the README details *right now*, when you happen to stumble on > them. When you see yourself thinking "Hey, I'll add this information > later into the Great Documentation I'm planning to have", slap yourself! > :-) Rather *immediately* dump the information, all raw, all unformatted, > into README. Do not even try to be proud of it, that would come later. > For now, just pour information in it at any opportunity. > >> May you open your own branch forked from trunk at lp? Could merge >> than all Pymacs diffs easily. > > Hey, let's move python-mode over to GitHub instead :-) And besides, if > people really think it is hopeless to ever get python-mode integrated > into Emacs, is there much remaining reason left, sticking with Bazaar? > > Keep happy! > > Fran?ois > > P.S. Behind the above tease, I hope you see my point: maintainers should > get away from this attitude of always attempting to pull all users (or > other maintainers) in their own playground. This is one of the aspects > I hate about trackers and other maintainer toys. While it's comfortable > for me to get a mere "pull request" on GitHub, I'd never try to force my > users into it, as it might not be comfortable for them. My comfort is > not *more worth* than theirs. > > > ------------------------------ > > Message: 4 > Date: Sun, 29 Jan 2012 13:40:47 -0500 > From: pinard at iro.umontreal.ca ( Fran?ois Pinard) > To: Andreas R?hler > Cc: python-mode at python.org > Subject: Re: [Python-mode] hide-show mode > Message-ID: <878vkq8i8g.fsf at iro.umontreal.ca> > Content-Type: text/plain; charset=utf-8 > > Andreas R?hler writes: > >> Make it a principle: "Users first!" :-) just my opinion. So let's >> proceed. > > Of course! > >> BTW in doc there is a commands list. Might it be of some use already? > > As doc/ stands, it is not much different from the Emacs Lisp sources > from which we would have subtracted Emacs Lisp. It's much better than > not having sources at all, but it's not essentially better than the > sources themselves, so it does not add value to the distribution. > > Unless I miss something, doc/ could almost go away. I use `C-h m' or > `C-h b' in activated Python mode to get the key bindings, you likely do > it this way also. So one sentence in README telling how to do `C-h m' > or `C-h b' could likely replace the interesting part of doc/, and maybe > more useful too. That's not good documentation yet, but that's a start. > > I doubt average Python users, not already familiar with Emacs Lisp, > could manage their way into doc/, but I may well be wrong on that! > > Fran?ois > > > ------------------------------ > > Message: 5 > Date: Sun, 29 Jan 2012 20:03:09 +0000 > From: Richard Everson > To: Andreas R?hler > Cc: "pymacs-devel at googlegroups.com" , > "python-mode at python.org" > Subject: Re: [Python-mode] Pymacs runs from python-mode > Message-ID: > Content-Type: text/plain; charset=iso-8859-1 > > > > On 29 Jan 2012, at 08:03, Andreas R?hler wrote: > >> Am 29.01.2012 04:24, schrieb Fran?ois Pinard: >>> Andreas R?hler writes: >>> >>>> If we provide the next Python-mode/Pymacs release using Make as Pymacs >>>> does, the top directory should contain only the minimal requiring, >>>> i.e, INSTALL, README etc. >>> >>> Hi, Andreas, and gang. >>> >>> Recently, I noticed that pymacs.el within python-mode (should be >>> Pymacs.el from now on), has a small local modification. When Emacs >>> launches the Python helper, it first does: >>> >>> " sys.path.insert(1, os.getenv('PYMACS_INSTALL_DIR'));" >>> >>> Let me comment a bit about this change: >>> >>> * Nowhere in python-mode README nor INSTALL, this PYMACS_INSTALL_DIR >>> environment variable is presented nor explained, while it really >>> should. Average Python mode users are unlikely to guess they have to >>> set this environment variable prior to calling Emacs. > > Hi, > > This was my ugly hack to enable Python to find Pymacs when Pymacs is distributed with python-mode.el and is therefore not on sys.path. There's nothing about it in README or INSTALL because I think it's purely local to the python-mode/pymacs interaction and the general user shouldn't need to know or do anything about it: that environment variable is set by python-mode.el. On the other hand, it would be *much* better to use the distributed, current version of Pymacs, but it's not clear to me how to achieve that if Pymacs is not installed somewhere on the standard sys.path. > > Best, > Richard. > > > > > ------------------------------ > > Message: 6 > Date: Sun, 29 Jan 2012 21:33:59 +0100 > From: Andreas R?hler > To: Fran?ois Pinard > Cc: pymacs-devel at googlegroups.com, python-mode at python.org > Subject: Re: [Python-mode] Pymacs runs from python-mode > Message-ID: <4F25AD37.2060106 at online.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > [ ... ] >>> May you open your own branch forked from trunk at lp? Could merge >>> than all Pymacs diffs easily. >> >> Hey, let's move python-mode over to GitHub instead :-) > > it's mirrored here: > > https://github.com/pdee/pdee/tree/master/python-modes/python-mode-el > > Should you make a branch, Pymacs stuff shaped as you want, I can merge > from there. > > > Andreas > > [ ... ] > > > ------------------------------ > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > > > End of Python-mode Digest, Vol 91, Issue 17 > ******************************************* From andreas.roehler at online.de Tue Jan 31 19:50:58 2012 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 31 Jan 2012 19:50:58 +0100 Subject: [Python-mode] py-ask-about-save Message-ID: <4F283812.9040700@online.de> 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 From pinard at iro.umontreal.ca Tue Jan 31 21:47:11 2012 From: pinard at iro.umontreal.ca (=?utf-8?Q?Fran=C3=A7ois?= Pinard) Date: Tue, 31 Jan 2012 15:47:11 -0500 Subject: [Python-mode] py-ask-about-save In-Reply-To: <4F283812.9040700@online.de> ("Andreas =?utf-8?Q?R=C3=B6hler?= =?utf-8?Q?=22's?= message of "Tue, 31 Jan 2012 19:50:58 +0100") References: <4F283812.9040700@online.de> Message-ID: <87wr87d2gg.fsf@iro.umontreal.ca> 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