From georg at python.org Wed Mar 3 00:12:58 2010 From: georg at python.org (Georg Brandl) Date: Wed, 03 Mar 2010 00:12:58 +0100 Subject: [Python-mode] Hello Message-ID: <4B8D9B7A.3050700@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've only just subscribed this list since I complained a bit to Barry about the general state of Python in Emacs and he managed to recruit me as a contributor :) I've used Emacs for quite a while now, and as a Python contributor, of course mainly doing Python development with one or another Python mode. cheers, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuNm3oACgkQN9GcIYhpnLAhOwCgoFhgWcdFT1OYGy69ESJiadFA iNMAnRkA+hvpbXT8QjYue3FYFJeWDBuT =yjeC -----END PGP SIGNATURE----- From barry at python.org Wed Mar 3 00:21:22 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 2 Mar 2010 18:21:22 -0500 Subject: [Python-mode] Hello In-Reply-To: <4B8D9B7A.3050700@python.org> References: <4B8D9B7A.3050700@python.org> Message-ID: <20100302182122.357e6f3b@heresy.wooz.org> On Mar 03, 2010, at 12:12 AM, Georg Brandl wrote: >I've only just subscribed this list since I complained a bit to Barry >about the general state of Python in Emacs and he managed to recruit >me as a contributor :) > >I've used Emacs for quite a while now, and as a Python contributor, of >course mainly doing Python development with one or another Python mode. Welcome Georg! You are now a member of ~python-mode-devs on Launchpad so you have commit privileges to the trunk. On IRC you mentioned that you use Emacs 23, which is what I use these days too. I don't use XEmacs any more, but I'm pretty sure I can test things out in that version if need be. Happy hacking, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jbauer at rubic.com Wed Mar 3 15:19:01 2010 From: jbauer at rubic.com (Jeff Bauer) Date: Wed, 03 Mar 2010 08:19:01 -0600 Subject: [Python-mode] Hello In-Reply-To: <4B8D9B7A.3050700@python.org> References: <4B8D9B7A.3050700@python.org> Message-ID: <4B8E6FD5.7090408@rubic.com> On 03/02/2010 05:12 PM, Georg Brandl wrote: > I've only just subscribed this list since I complained a bit to Barry > about the general state of Python in Emacs and he managed to recruit > me as a contributor :) Hi Georg! Any cool Python/Emacs tricks you'd care to share? (Or Barry?) Jeff "Shaun White" Bauer Rubicon, Inc. From georg at python.org Thu Mar 4 22:35:36 2010 From: georg at python.org (Georg Brandl) Date: Thu, 04 Mar 2010 22:35:36 +0100 Subject: [Python-mode] Hello In-Reply-To: <4B8E6FD5.7090408@rubic.com> References: <4B8D9B7A.3050700@python.org> <4B8E6FD5.7090408@rubic.com> Message-ID: <4B9027A8.8050901@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.03.2010 15:19, schrieb Jeff Bauer: > On 03/02/2010 05:12 PM, Georg Brandl wrote: >> I've only just subscribed this list since I complained a bit to Barry >> about the general state of Python in Emacs and he managed to recruit >> me as a contributor :) > > Hi Georg! > > Any cool Python/Emacs tricks you'd care to share? (Or Barry?) Well, not as such, but you can look at my .emacs.d here: http://bitbucket.org/birkenfeld/dotemacs/ cheers, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuQJ6gACgkQN9GcIYhpnLCvjgCfVsON5dW0K6wUv1oYN/cIKwAJ PC0Ani1N9fH1HBPSB+D7EmdiS4Uf/Tp/ =Ew0d -----END PGP SIGNATURE----- From andreas.roehler at online.de Fri Mar 5 19:00:07 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 05 Mar 2010 19:00:07 +0100 Subject: [Python-mode] small units Message-ID: <4B9146A7.30506@online.de> Hi, question is: how to edit small units in python-code? Let's consider piece below from Dive Into Python: result = roman71.fromRoman(numeral) Beside of operators three python-words are here: result / roman71 / fromRoman(numeral) which should possible be picked with one command/key. Resp. copied, deleted, maybe transposed etc. Any ideas? Thanks Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Sun Mar 7 22:53:42 2010 From: barry at python.org (Barry Warsaw) Date: Sun, 7 Mar 2010 16:53:42 -0500 Subject: [Python-mode] small units In-Reply-To: <4B9146A7.30506@online.de> References: <4B9146A7.30506@online.de> Message-ID: <20100307165342.3d7ea26a@heresy.wooz.org> On Mar 05, 2010, at 07:00 PM, Andreas Roehler wrote: >question is: how to edit small units in python-code? > >Let's consider piece below from Dive Into Python: > > result = roman71.fromRoman(numeral) > >Beside of operators three python-words are here: > >result / roman71 / fromRoman(numeral) > >which should possible be picked with one command/key. >Resp. copied, deleted, maybe transposed etc. Aren't there already key bindings for these. E.g. M-f == py-forward-into-nomenclature M-C-f == forward-sexp Well you need two keystrokes to get all of 'fromRoman(numeral)' or of course you could just use C-e == move-end-of-line At least, it's never seemed there was anything lacking to me. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From rohan.nicholls at googlemail.com Mon Mar 8 21:42:51 2010 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Mon, 8 Mar 2010 21:42:51 +0100 Subject: [Python-mode] small units In-Reply-To: <20100307165342.3d7ea26a@heresy.wooz.org> References: <4B9146A7.30506@online.de> <20100307165342.3d7ea26a@heresy.wooz.org> Message-ID: I second this, I find the emacs movement bindings work brilliantly. And if it is a long line, I use incremental search to navigate. On Sun, Mar 7, 2010 at 10:53 PM, Barry Warsaw wrote: > On Mar 05, 2010, at 07:00 PM, Andreas Roehler wrote: > >>question is: how to edit small units in python-code? >> >>Let's consider piece below from Dive Into Python: >> >> ?result = roman71.fromRoman(numeral) >> >>Beside of operators three python-words are here: >> >>result / roman71 / fromRoman(numeral) >> >>which should possible be picked with one command/key. >>Resp. copied, deleted, maybe transposed etc. I am not sure what you mean by one command/key, could you elaborate? I am curious what you are searching for. Have you seen this functionality elsewhere? Could you give a specific example? Thanks, Rohan From andreas.roehler at online.de Mon Mar 8 22:39:51 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 08 Mar 2010 22:39:51 +0100 Subject: [Python-mode] small units In-Reply-To: <20100307165342.3d7ea26a@heresy.wooz.org> References: <4B9146A7.30506@online.de> <20100307165342.3d7ea26a@heresy.wooz.org> Message-ID: <4B956EA7.9040204@online.de> Barry Warsaw wrote: > On Mar 05, 2010, at 07:00 PM, Andreas Roehler wrote: > >> question is: how to edit small units in python-code? >> >> Let's consider piece below from Dive Into Python: >> >> result = roman71.fromRoman(numeral) >> >> Beside of operators three python-words are here: >> >> result / roman71 / fromRoman(numeral) >> >> which should possible be picked with one command/key. >> Resp. copied, deleted, maybe transposed etc. > > Aren't there already key bindings for these. E.g. > > M-f == py-forward-into-nomenclature that's ok Python-units, `python-expressions' finally, behaves different: 1) it selects and highlights the item 2) stops at the beginning, resp. the last char of item 3) takes the item into the kill-ring when interactively called 4) provides a series of related commands, reports, hiding etc. > M-C-f == forward-sexp Shows occasionally unpredictable behaviour, for example def __init__(self, d={}): __________________________|______ self._keys = d.keys() dict.__init__(self, d) If cursor is under closing brace forward-sexp: Scan error: "Containing expression ends prematurely", 565, 566 `ar-forward-python-expression-atpt' in contrast would move to the closing `)' with first step, than to the next `self' etc. BTW seems I have to clean up my launchpad-repo For the curious, in order to get everything needed, two checkouts seem necessary: bzr branch lp:~a-roehler/s-x-emacs-werkstatt/thingatpt-python-expressions.el bzr branch lp:~a-roehler/s-x-emacs-werkstatt/beg-end.el Andreas > > Well you need two keystrokes to get all of 'fromRoman(numeral)' or of course > you could just use > > C-e == move-end-of-line > > At least, it's never seemed there was anything lacking to me. > > -Barry > > > ------------------------------------------------------------------------ > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From marc.massar at gmail.com Thu Mar 11 17:19:03 2010 From: marc.massar at gmail.com (Marc Massar) Date: Thu, 11 Mar 2010 11:19:03 -0500 Subject: [Python-mode] Python shell not responding Message-ID: Hi, After running py-shell I get an error message in the min-buffer "Wrong type argument: processp, nil". The *Python* buffer shows: Python 2.6 (r26:66714, Dec 23 2009, 15:54:18) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> I can type things, but hitting RET just gives me a new line (no prompt) and nothing more. This happens with emacs 23.1.1 and Python 2.6 (under Linux), and emacs 22.1.1 with Python 2.6 and 2.4.4 (I tried both) under Solaris. This was tested running emacs -Q, so it is not related to local configuration. Any idea how to solve this? Thanks in advance, Marc From andreas.roehler at online.de Fri Mar 12 10:51:17 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 12 Mar 2010 10:51:17 +0100 Subject: [Python-mode] form inserting print Message-ID: <4B9A0E95.5090908@online.de> Hi python-mode folks, form below should speed up writing print-statements in Python a little bit. (defun druck (&optional arg) "Inserts a print statement out of current `(car kill-ring)' by default, inserts ARG instead if delivered. " (interactive "*") (lexical-let* ((name (or arg (car kill-ring))) (form (cond ((eq major-mode 'python-mode) (concat "print \"" name ": %s \" % " name))))) (insert form))) Opinions? Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From georg at python.org Fri Mar 12 11:21:36 2010 From: georg at python.org (Georg Brandl) Date: Fri, 12 Mar 2010 11:21:36 +0100 Subject: [Python-mode] form inserting print In-Reply-To: <4B9A0E95.5090908@online.de> References: <4B9A0E95.5090908@online.de> Message-ID: <4B9A15B0.1070508@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.03.2010 10:51, schrieb Andreas Roehler: > Hi python-mode folks, > > form below should speed up writing print-statements in Python a > little bit. > > (defun druck (&optional arg) > "Inserts a print statement out of current `(car kill-ring)' by default, inserts ARG instead if delivered. " > (interactive "*") > (lexical-let* ((name (or arg (car kill-ring))) > (form (cond ((eq major-mode 'python-mode) > (concat "print \"" name ": %s \" % " name))))) > (insert form))) > > Opinions? Wouldn't that be the job of one of the numerous snippet packages that are floating around? I'm using yasnippet myself, and it works very well. (I know that python.el has some definitions for skeleton mode, but python-mode.el doesn't, and I'm not sure it should.) Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuaFbAACgkQN9GcIYhpnLDOGgCgsLnSpHSv000OzmCvrxwZDXzx cwQAni9nFX3hIeZ3Di3bCtVHaCAClnlm =Syty -----END PGP SIGNATURE----- From barry at python.org Fri Mar 12 16:21:28 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 12 Mar 2010 10:21:28 -0500 Subject: [Python-mode] form inserting print In-Reply-To: <4B9A15B0.1070508@python.org> References: <4B9A0E95.5090908@online.de> <4B9A15B0.1070508@python.org> Message-ID: <20100312102128.09de9abf@heresy.wooz.org> On Mar 12, 2010, at 11:21 AM, Georg Brandl wrote: >Wouldn't that be the job of one of the numerous snippet packages that are >floating around? I'm using yasnippet myself, and it works very well. >(I know that python.el has some definitions for skeleton mode, but >python-mode.el doesn't, and I'm not sure it should.) I'm not sure either. python-mode.el does contain some hooks for imenu so there's some precedence. I guess if we're going to support such functionality, it should be via standard available hooks. I don't use stuff like that much though, so I don't have a strong opinion either way. -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 Mar 12 22:16:15 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 12 Mar 2010 22:16:15 +0100 Subject: [Python-mode] form inserting print In-Reply-To: <4B9A15B0.1070508@python.org> References: <4B9A0E95.5090908@online.de> <4B9A15B0.1070508@python.org> Message-ID: <4B9AAF1F.2010105@online.de> Georg Brandl wrote: > Am 12.03.2010 10:51, schrieb Andreas Roehler: >> Hi python-mode folks, > >> form below should speed up writing print-statements in Python a >> little bit. > >> (defun druck (&optional arg) >> "Inserts a print statement out of current `(car kill-ring)' by default, inserts ARG instead if delivered. " >> (interactive "*") >> (lexical-let* ((name (or arg (car kill-ring))) >> (form (cond ((eq major-mode 'python-mode) >> (concat "print \"" name ": %s \" % " name))))) >> (insert form))) > >> Opinions? > > Wouldn't that be the job of one of the numerous snippet packages that are > floating around? Probably. I'm using yasnippet myself, and it works very well. For me too. > (I know that python.el has some definitions for skeleton mode, but > python-mode.el doesn't, and I'm not sure it should.) Thanks for the hint. `python-expand-template' works fine for me. For conditionals starting with `if' or `try' it should pay having it. Andreas > > Georg From andreas.roehler at online.de Sat Mar 13 12:51:12 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Sat, 13 Mar 2010 12:51:12 +0100 Subject: [Python-mode] 23.1.92; python-expand-template docu Message-ID: <4B9B7C30.5040101@online.de> Hi, python.el provides templates inserting compound statements like `if', `for' etc. - a nice feature. AFAIS it's for use in two ways - 1) as an abbrev expanded 2) by calling `python-expand-template', afterwards the user is prompted. See only the first usage mentioned in the docu. The latter may be more suitable for beginners, as it's done expressingly only - no automatic abbreviation expansion. Suggest to extend the docstring of `python-use-skeletons' with something like "In any case you may use skeletons, calling `python-expand-template'." Also description of `define-derived-mode python-mode' which closes now: "An abbrev table is set up with skeleton expansions for compound statement templates." should mention `python-use-skeletons'. Thanks all Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ GNU Emacs 23.1.92.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2010-02-19 From benbeecher at gmail.com Sat Mar 13 18:35:52 2010 From: benbeecher at gmail.com (Ben Beecher) Date: Sat, 13 Mar 2010 12:35:52 -0500 Subject: [Python-mode] Hey Message-ID: HI all - I've just joined the list. I'd like to contribute, although I don't have alot of experience with open source projects. How can I best help out? I'll pull the latest off of launchpad of course, but what would do the most good? Feature requests? Feature implantations? Bug Triage? Looking forward to helping out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.roehler at online.de Sun Mar 14 18:45:12 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 14 Mar 2010 18:45:12 +0100 Subject: [Python-mode] form inserting print In-Reply-To: <20100312102128.09de9abf@heresy.wooz.org> References: <4B9A0E95.5090908@online.de> <4B9A15B0.1070508@python.org> <20100312102128.09de9abf@heresy.wooz.org> Message-ID: <4B9D20A8.6060702@online.de> Barry Warsaw wrote: > On Mar 12, 2010, at 11:21 AM, Georg Brandl wrote: > >> Wouldn't that be the job of one of the numerous snippet packages that are >> floating around? I'm using yasnippet myself, and it works very well. >> (I know that python.el has some definitions for skeleton mode, but >> python-mode.el doesn't, and I'm not sure it should.) > > I'm not sure either. python-mode.el does contain some hooks for imenu so > there's some precedence. I guess if we're going to support such > functionality, it should be via standard available hooks. > > I don't use stuff like that much though, so I don't have a strong opinion > either way. > > -Barry Hi Barry, created a new branch, added skeletons inserting compound statements from python.el Thought it's easier to debug/maintain having it in a separate file `python-mode-skeletons.el' Below a bash-script used for checking. RET or should start the skeleton. Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ ;;;;;;;;;;;;; LOCAL_PYTHON_BRANCH_PATH= ... edit emacs -q -L $HOME/$LOCAL_PYTHON_BRANCH_PATH --debug-init -l $HOME/${LOCAL_PYTHON_BRANCH_PATH}/python-mode.el --find-file=$HOME/my-test.py --eval=\"(erase-buffer)\" --eval=\"(abbrev-mode 1)\" --eval='(insert \"for\")' --funcall=describe-mode &" From barry at python.org Sun Mar 14 20:33:24 2010 From: barry at python.org (Barry Warsaw) Date: Sun, 14 Mar 2010 15:33:24 -0400 Subject: [Python-mode] Hey In-Reply-To: References: Message-ID: <20100314153324.2d5d12c5@heresy.wooz.org> On Mar 13, 2010, at 12:35 PM, Ben Beecher wrote: >HI all - I've just joined the list. I'd like to contribute, although I don't >have alot of experience with open source projects. How can I best help out? >I'll pull the latest off of launchpad of course, but what would do the most >good? Feature requests? Feature implantations? Bug Triage? > >Looking forward to helping out. Welcome aboard Ben! Bug triage would certain be very welcome. We currently have 69 open bugs on the tracker, and they could use more love. Another interesting thing would be to review the standard python.el and see what tricks we can steal from them. Hey, we're all GPL here, right? :) If you have XEmacs, you might also look at compatibility issues between the two editors. -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 Tue Mar 16 11:44:25 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 16 Mar 2010 11:44:25 +0100 Subject: [Python-mode] [Fwd: plan for emacs python tooling (esp python.el, python-mode.el)?] Message-ID: <4B9F6109.80606@online.de> An embedded message was scrubbed... From: Tom Roche Subject: plan for emacs python tooling (esp python.el, python-mode.el)? Date: Mon, 15 Mar 2010 12:47:53 -0400 Size: 8365 URL: From andreas.roehler at online.de Tue Mar 16 11:44:41 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 16 Mar 2010 11:44:41 +0100 Subject: [Python-mode] [Fwd: Re: plan for emacs python tooling (esp python.el, python-mode.el)?] Message-ID: <4B9F6119.7080700@online.de> An embedded message was scrubbed... From: Stefan Monnier Subject: Re: plan for emacs python tooling (esp python.el, python-mode.el)? Date: Mon, 15 Mar 2010 23:58:04 -0400 Size: 3680 URL: From andreas.roehler at online.de Tue Mar 16 11:47:57 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 16 Mar 2010 11:47:57 +0100 Subject: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)? In-Reply-To: References: <87sk81cz0m.fsf@pobox.com> Message-ID: <4B9F61DD.4050507@online.de> Stefan Monnier wrote: >> summary: Is the near-term plan for GNU emacs (e.g. for 2010-2011) to >> ship with python.el, python-mode.el, both, or something completely >> different? > > The plan is to ship it with python.el until we can ship it with > python-mode.el (the barrier being coipyright assignments). > > > Stefan > > > Hi Stefan, as far as I understand the OP, the focus is rather the python-environment than the editor. As far as it concerns editing, python.el, python-mode.el are both suitable IMHO. Don't see a real gain by switching one for the other. If a precise feature is missed here or there, let's implement it... Progress would mean having a download source for an environment, which offers all needed at once: debugging, refactoring, auto-completion etc. Such an environment should enable emacs editing modes, but vim and other free tools too. Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From andreas.roehler at online.de Tue Mar 16 14:24:07 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 16 Mar 2010 14:24:07 +0100 Subject: [Python-mode] compound-statement-skeletons Message-ID: <4B9F8677.4090406@online.de> Hi Barry, hi all, transferred `compound-statement-skeletons' from python.el in order to work with python-mode.el. It defines "if", "for" etc. as abbrevs, whose expansions are functions inserting the skeleton. Remains a strange bug: abbrev-expansion only works after a RET inside the buffer or a manual call "M-x python-expand-skeleton" first. If that is called one time, expanding abbrevs/skeletons works fine. Any idea whats wrong? The bug doesn't exist when called from python.el Thanks Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From sesquile at gmail.com Tue Mar 16 16:39:29 2010 From: sesquile at gmail.com (m h) Date: Tue, 16 Mar 2010 09:39:29 -0600 Subject: [Python-mode] Hey In-Reply-To: <20100314153324.2d5d12c5@heresy.wooz.org> References: <20100314153324.2d5d12c5@heresy.wooz.org> Message-ID: On Sun, Mar 14, 2010 at 1:33 PM, Barry Warsaw wrote: > On Mar 13, 2010, at 12:35 PM, Ben Beecher wrote: > >>HI all - I've just joined the list. I'd like to contribute, although I don't >>have alot of experience with open source projects. How can I best help out? >>I'll pull the latest off of launchpad of course, but what would do the most >>good? Feature requests? Feature implantations? Bug Triage? >> >>Looking forward to helping out. > > Welcome aboard Ben! > > Bug triage would certain be very welcome. ?We currently have 69 open bugs on > the tracker, and they could use more love. ?Another interesting thing would be > to review the standard python.el and see what tricks we can steal from them. > Hey, we're all GPL here, right? :) On this note, it might be nice to create a wiki page (python.el vs python-mode.el) elaborating the different features found in each.... -matt From barry at python.org Tue Mar 16 21:55:06 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 16 Mar 2010 16:55:06 -0400 Subject: [Python-mode] Hey In-Reply-To: References: <20100314153324.2d5d12c5@heresy.wooz.org> Message-ID: <20100316165506.69a2b298@heresy> On Mar 16, 2010, at 09:39 AM, m h wrote: >On this note, it might be nice to create a wiki page (python.el vs >python-mode.el) elaborating the different features found in each.... Like this one: http://www.emacswiki.org/emacs/PythonMode Could use lots of clean up though. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Tue Mar 16 22:20:06 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 16 Mar 2010 17:20:06 -0400 Subject: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)? In-Reply-To: <4B9F61DD.4050507@online.de> References: <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> Message-ID: <20100316172006.5ad2ba69@heresy> >> The plan is to ship it with python.el until we can ship it with >> python-mode.el (the barrier being coipyright assignments). Although I believe I've already done so, I've repeatedly said that I have no problem assigning my changes in python-mode.el to the FSF (again). I think we can get Skip, Ken, and Tim to do the same, though I also think some or all of them have already done so. I really don't know what more I can do about the copyright assignment "problem". That having been said, python-mode.el is GPL and I nothing against y'all stealing as much from python.el as makes sense. If python-mode.el is never distributed with Emacs, so be it. But there really shouldn't be anything stopping python-mode.el from having the best of both worlds. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From sesquile at gmail.com Tue Mar 16 23:19:05 2010 From: sesquile at gmail.com (m h) Date: Tue, 16 Mar 2010 16:19:05 -0600 Subject: [Python-mode] Hey In-Reply-To: <20100316165506.69a2b298@heresy> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> Message-ID: On Tue, Mar 16, 2010 at 2:55 PM, Barry Warsaw wrote: > On Mar 16, 2010, at 09:39 AM, m h wrote: > >>On this note, it might be nice to create a wiki page (python.el vs >>python-mode.el) elaborating the different features found in each.... > > Like this one: > > http://www.emacswiki.org/emacs/PythonMode > > Could use lots of clean up though. Well, that one could use some work too. My thought was to have a page that just lists a table with rows for features and 2 columns, python.el and python-mode.el. Then below perhaps some discussion about why one would use one versus the other. When new people come to the python/emacs world it is confusing (to say the least that there are two modes), and there isn't anywhere that explains the features of both. The page you point isn't really python "mode" specific anymore. It is more of using Python and emacs together for various features (some of which are in python(-mode).el, and some aren't). -matt From barry at python.org Wed Mar 17 00:12:50 2010 From: barry at python.org (Barry Warsaw) Date: Tue, 16 Mar 2010 19:12:50 -0400 Subject: [Python-mode] Hey In-Reply-To: References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> Message-ID: <20100316191250.359f4dc9@heresy> On Mar 16, 2010, at 04:19 PM, m h wrote: >Well, that one could use some work too. My thought was to have a page >that just lists a table with rows for features and 2 columns, >python.el and python-mode.el. Then below perhaps some discussion >about why one would use one versus the other. When new people come to >the python/emacs world it is confusing (to say the least that there >are two modes), and there isn't anywhere that explains the features of >both. > >The page you point isn't really python "mode" specific anymore. It is >more of using Python and emacs together for various features (some of >which are in python(-mode).el, and some aren't). I guess the question is, if the page you describe (which I agree would be good to have) is not on the EmacsWiki, where would it be? Isn't that likely to be the first place people would search for such a page? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From sesquile at gmail.com Wed Mar 17 01:49:16 2010 From: sesquile at gmail.com (m h) Date: Tue, 16 Mar 2010 18:49:16 -0600 Subject: [Python-mode] Hey In-Reply-To: <20100316191250.359f4dc9@heresy> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <20100316191250.359f4dc9@heresy> Message-ID: On Tue, Mar 16, 2010 at 5:12 PM, Barry Warsaw wrote: > On Mar 16, 2010, at 04:19 PM, m h wrote: > >>Well, that one could use some work too. ?My thought was to have a page >>that just lists a table with rows for features and 2 columns, >>python.el and python-mode.el. ?Then below perhaps some discussion >>about why one would use one versus the other. ?When new people come to >>the python/emacs world it is confusing (to say the least that there >>are two modes), and there isn't anywhere that explains the features of >>both. >> >>The page you point isn't really python "mode" specific anymore. ?It is >>more of using Python and emacs together for various features (some of >>which are in python(-mode).el, and some aren't). > > I guess the question is, if the page you describe (which I agree would be good > to have) is not on the EmacsWiki, where would it be? ?Isn't that likely to be > the first place people would search for such a page? > I think you are right. The topic of that page is "using emacs with Python development". A subset of which is a Python mode to choose. I guess I would prefer a "Python with Emacs" that contains a much cleaned up version of the current "python-mode" page, and a "python.el vs python-mode.el" page as I have described.... -matt From deniz.a.m.dogan at gmail.com Wed Mar 17 10:09:40 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Wed, 17 Mar 2010 10:09:40 +0100 Subject: [Python-mode] Hey In-Reply-To: <20100316165506.69a2b298@heresy> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> Message-ID: <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> 2010/3/16 Barry Warsaw : > On Mar 16, 2010, at 09:39 AM, m h wrote: > >>On this note, it might be nice to create a wiki page (python.el vs >>python-mode.el) elaborating the different features found in each.... > > Like this one: > > http://www.emacswiki.org/emacs/PythonMode > > Could use lots of clean up though. > -Barry > I think the main problem about that wiki entry is that it's on EmacsWiki. Most EmacsWiki entries look just like that, everything ends up a discussion board and/or bunch of recipes for unrelated features. -- Deniz Dogan From andreas.roehler at online.de Wed Mar 17 10:30:23 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Wed, 17 Mar 2010 10:30:23 +0100 Subject: [Python-mode] Hey In-Reply-To: <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> Message-ID: <4BA0A12F.2030104@online.de> Deniz Dogan wrote: > 2010/3/16 Barry Warsaw : >> On Mar 16, 2010, at 09:39 AM, m h wrote: >> >>> On this note, it might be nice to create a wiki page (python.el vs >>> python-mode.el) elaborating the different features found in each.... >> Like this one: >> >> http://www.emacswiki.org/emacs/PythonMode >> >> Could use lots of clean up though. >> -Barry >> > > I think the main problem about that wiki entry is that it's on > EmacsWiki. Most EmacsWiki entries look just like that, everything ends > up a discussion board and/or bunch of recipes for unrelated features. > Isn't that a feature rather characteristic of all wikis? EmacsWiki does very well in relation, provides a lot of useful stuff IMO. Download facility is excellent. Andreas From deniz.a.m.dogan at gmail.com Wed Mar 17 12:03:24 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Wed, 17 Mar 2010 12:03:24 +0100 Subject: [Python-mode] Hey In-Reply-To: <4BA0A12F.2030104@online.de> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> <4BA0A12F.2030104@online.de> Message-ID: <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> 2010/3/17 Andreas Roehler : > Deniz Dogan wrote: >> 2010/3/16 Barry Warsaw : >>> On Mar 16, 2010, at 09:39 AM, m h wrote: >>> >>>> On this note, it might be nice to create a wiki page (python.el vs >>>> python-mode.el) elaborating the different features found in each.... >>> Like this one: >>> >>> http://www.emacswiki.org/emacs/PythonMode >>> >>> Could use lots of clean up though. >>> -Barry >>> >> >> I think the main problem about that wiki entry is that it's on >> EmacsWiki. Most EmacsWiki entries look just like that, everything ends >> up a discussion board and/or bunch of recipes for unrelated features. >> > > Isn't that a feature rather characteristic of all wikis? > > EmacsWiki does very well in relation, provides a lot of useful stuff IMO. > Download facility is excellent. > EmacsWiki _is_ useful, I use it all the time. I'm just saying there are huge problems with mixing discussion and actual information on one page, especially as there is absolutely no visual indication about what's what. In relation to what do you think that EmacsWiki does very well? -- Deniz Dogan From andreas.roehler at online.de Wed Mar 17 13:28:47 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Wed, 17 Mar 2010 13:28:47 +0100 Subject: [Python-mode] Hey In-Reply-To: <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> <4BA0A12F.2030104@online.de> <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> Message-ID: <4BA0CAFF.70506@online.de> Deniz Dogan wrote: > 2010/3/17 Andreas Roehler : >> Deniz Dogan wrote: >>> 2010/3/16 Barry Warsaw : >>>> On Mar 16, 2010, at 09:39 AM, m h wrote: >>>> >>>>> On this note, it might be nice to create a wiki page (python.el vs >>>>> python-mode.el) elaborating the different features found in each.... >>>> Like this one: >>>> >>>> http://www.emacswiki.org/emacs/PythonMode >>>> >>>> Could use lots of clean up though. >>>> -Barry >>>> >>> I think the main problem about that wiki entry is that it's on >>> EmacsWiki. Most EmacsWiki entries look just like that, everything ends >>> up a discussion board and/or bunch of recipes for unrelated features. >>> >> Isn't that a feature rather characteristic of all wikis? >> >> EmacsWiki does very well in relation, provides a lot of useful stuff IMO. >> Download facility is excellent. >> > > EmacsWiki _is_ useful, I use it all the time. I'm just saying there > are huge problems with mixing discussion and actual information on one > page, especially as there is absolutely no visual indication about > what's what. In relation to what do you think that EmacsWiki does very > well? > In relation to other wikis I've seen: dead links, unrelated, outdated stuff, sometimes even smear and slander. Seems thats normal, wikis are a kind of marketplaces: rather loud, with dirty corners. However, if you got your vegetables, it's done, it's great. So I'm rather in favour of EmacsWiki, inclusive it's clowns corner. :-) Andreas From barry at python.org Wed Mar 17 13:37:15 2010 From: barry at python.org (Barry Warsaw) Date: Wed, 17 Mar 2010 08:37:15 -0400 Subject: [Python-mode] Hey In-Reply-To: <4BA0CAFF.70506@online.de> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> <4BA0A12F.2030104@online.de> <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> <4BA0CAFF.70506@online.de> Message-ID: <5B63B67C-20A1-4605-AE6A-C3A511C7AE4D@python.org> On Mar 17, 2010, at 8:28 AM, Andreas Roehler wrote: > Seems thats normal, wikis are a kind of marketplaces: rather loud, with dirty corners. > However, if you got your vegetables, it's done, it's great. > So I'm rather in favour of EmacsWiki, inclusive it's clowns corner. :-) The fundamental nature of wikis is that they always need gardening. I still don't know of any place better to put this information. -Barry From andreas.roehler at online.de Wed Mar 17 16:40:57 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Wed, 17 Mar 2010 16:40:57 +0100 Subject: [Python-mode] Hey In-Reply-To: <5B63B67C-20A1-4605-AE6A-C3A511C7AE4D@python.org> References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> <4BA0A12F.2030104@online.de> <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> <4BA0CAFF.70506@online.de> <5B63B67C-20A1-4605-AE6A-C3A511C7AE4D@python.org> Message-ID: <4BA0F809.5030906@online.de> Barry Warsaw wrote: > On Mar 17, 2010, at 8:28 AM, Andreas Roehler wrote: > >> Seems thats normal, wikis are a kind of marketplaces: rather loud, with dirty corners. >> However, if you got your vegetables, it's done, it's great. >> So I'm rather in favour of EmacsWiki, inclusive it's clowns corner. :-) > > The fundamental nature of wikis is that they always need gardening. > > I still don't know of any place better to put this information. > -Barry > > Nor do I. BTW as far as it concerns emacs lisp snippets I store stuff at http://repo.or.cz/w/elbb.git It allows playing with git too, which is a great DVC indeed, it's open for all emacs folks. Andreas From andreas.roehler at online.de Thu Mar 18 09:50:41 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Thu, 18 Mar 2010 09:50:41 +0100 Subject: [Python-mode] bazaar merge oddity Message-ID: <4BA1E961.60600@online.de> Hi Barry, after a merge bazaar requires a local commit nonetheless. However, the difficulty and confusion IMHO arises from the commit-message, necessary that way also. As you may see in the current trunk now, your revision 353 is gone completely. It's place is taken by my patch, while your changing appears as rev 354 but with my commit message. Or made I some mistake? Cheers Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Thu Mar 18 13:29:31 2010 From: barry at python.org (Barry Warsaw) Date: Thu, 18 Mar 2010 08:29:31 -0400 Subject: [Python-mode] bazaar merge oddity In-Reply-To: <4BA1E961.60600@online.de> References: <4BA1E961.60600@online.de> Message-ID: <20100318082931.78d9efed@heresy> On Mar 18, 2010, at 09:50 AM, Andreas Roehler wrote: >after a merge bazaar requires a local commit nonetheless. > >However, the difficulty and confusion IMHO arises from >the commit-message, necessary that way also. > >As you may see in the current trunk now, your revision >353 is gone completely. > >It's place is taken by my patch, while your changing >appears as rev 354 but with my commit message. > >Or made I some mistake? I don't think you made any mistake, I think it's just the way dvcs in general, and Bazaar in particular handles things. The fundamental problem of course is that revision numbers (e.g. 353) are by definition local and not stable. If I were to commit a change now, it would be r355 locally. If you did the same thing we'd both have r355 in our local repositories. The first one of us to push to the master branch would "win" and the second would have to first merge and then push, which I'm sure is what you did. Every revision also has a "revision id", which is a globally unique, but not human friendly, id that will never change. % bzr log -c 354 --show-ids ------------------------------------------------------------ revno: 354 [merge] revision-id: andreas.roehler at online.de-20100318083644-0msjrlaxvmv4mlvl parent: andreas.roehler at online.de-20100123170127-dqmdxlkb156bncvb parent: barry at python.org-20100119204450-7iekyt7gnxw2qhfn committer: Andreas Roehler branch nick: 328781-bod-lands-in-string timestamp: Thu 2010-03-18 09:36:44 +0100 message: revision/353 Fix some indentation merged ------------------------------------------------------------ Use --include-merges or -n0 to see merged revisions. You can see that the parent of your change is my indentation change: % bzr log -c barry at python.org-20100119204450-7iekyt7gnxw2qhfn ------------------------------------------------------------ revno: 352.1.1 committer: Barry Warsaw branch nick: python-mode timestamp: Tue 2010-01-19 15:44:50 -0500 message: Fix some indentation. and the revno gets a dotted path, which is unique to the master branch (and once you've reconciled/merged it to your local branch, yours as well). This shows the parenting relationship between the revisions. Normally, this is hidden because it's mostly uninteresting, but it does make things confusing in cases like this. Suffice to say that Bazaar makes it pretty difficult for you to do anything destructive like "lose" a revision. IOW, you did the right thing! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From eric at siege-engine.com Tue Mar 16 12:37:13 2010 From: eric at siege-engine.com (Eric M. Ludlam) Date: Tue, 16 Mar 2010 07:37:13 -0400 Subject: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)? In-Reply-To: <4B9F61DD.4050507@online.de> References: <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> Message-ID: <4B9F6D69.4020909@siege-engine.com> On 03/16/2010 06:47 AM, Andreas Roehler wrote: > as far as I understand the OP, the focus is rather the python-environment than the editor. > > As far as it concerns editing, python.el, python-mode.el are both suitable IMHO. > > Don't see a real gain by switching one for the other. If a precise feature is missed here or there, let's implement it... > > Progress would mean having a download source for an environment, which offers all needed at once: > debugging, refactoring, auto-completion etc. > > Such an environment should enable emacs editing modes, but vim and other free tools too. The CEDET support for python parsing (which would handle autocompletion type tasks amonng others) is also (as far as I know) held up by a copyright assignment. Exuberent ctags supports python (though I don't know by how much), and adding support in the CEDET/Semantic exuberant ctags support wouldn't be too hard. Likely something like the patch attached. Hmmm. I see that the exuberent ctags support does not appear to be a part of Emacs. Well, you could try the most recently posted version of CEDET with the below patch instead if you wanted to try it. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: semantic-ectag-lang.el.patch Type: text/x-diff Size: 1656 bytes Desc: not available URL: From Tom_Roche at pobox.com Tue Mar 16 15:43:19 2010 From: Tom_Roche at pobox.com (Tom Roche) Date: Tue, 16 Mar 2010 10:43:19 -0400 Subject: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)? In-Reply-To: <4B9F6D69.4020909@siege-engine.com> References: <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> Message-ID: <87k4tccooo.fsf@pobox.com> summary: I'll followup with the python*el folks and CEDET regarding current and future python development environments for GNU emacs. details: Tom Roche Mon, Mar 15, 2010 at 11:47 AM >>>> Is the near-term plan for GNU emacs (e.g. for 2010-2011) to ship >>>> with python.el, python-mode.el, both, or something completely >>>> different? Stefan Monnier Mon, 15 Mar 2010 23:58:04 -0400 >>> The plan is to ship it with python.el until we can ship it with >>> python-mode.el (the barrier being [copyright] assignments). Given the duration of that barrier to date, ISTM one must assume python-mode.el's copyrights won't be assigned. Andreas Roehler Tue, 16 Mar 2010 11:47:57 +0100 (rearranged) >> as far as I understand the OP, the focus is rather the python- >> environment than the editor. That is technically correct, but (I suspect, and ICBW) practically, * the python development environment needs a platform. * Given that coding python ~= editing test files, that platform is most reasonably a text editor. Hence I want a >>>> PDEE ? la the JDEE http://jdee.sourceforge.net/ >>>>> A Java Development Environment for Emacs ... >>>>> JDEE features include ... >>>>> * syntax coloring >>>>> * auto indentation >>>>> * compile error to source links >>>>> * source-level debugging >>>>> * source code browsing >>>>> * make file support >>>>> * automatic code generation IIUC this is the "best of breed" code environment for GNU emacs (am I missing something?) so I regard it as a model. >> Such an environment should enable emacs editing modes, but vim and >> other free tools too. Again, technically correct, but * I want a python development environment for GNU emacs, since that's what my fingers know. (Which is why I'm not (at least initially) getting Wing or PyDev: I'd end up using emacs to edit the files underneath, as I was forced to do when working on Eclipse.) * The *macs ecosystem already contains robust tools for providing coder services (e.g. the "JDEE features" above), e.g. CEDET. Since the JDEE definitely exploits CEDET, and GNU emacs is apparently in the process of integrating CEDET (no?), I tend to assume a PDEE should do this too. * I don't see the editor-independent interfaces to the services above. Am I missing something? (I am very new to python.) If the above is true, then it seems the fastpath to a richer PDEE is CEDET integration. No? Except ... Eric M. Ludlam Tue, 16 Mar 2010 07:37:13 -0400 > The CEDET support for python parsing (which would handle > autocompletion type tasks [among] others) is also (as far as I know) > held up by a copyright assignment. I'll followup about that separately. your assistance is appreciated, Tom Roche From Tom_Roche at pobox.com Tue Mar 16 21:22:11 2010 From: Tom_Roche at pobox.com (Tom Roche) Date: Tue, 16 Mar 2010 16:22:11 -0400 Subject: [Python-mode] simple comment/string-tweak branch Message-ID: <87bpeoqaoc.fsf@pobox.com> Preparatory to an upcoming post on using/improving python-mode, I looked @ the code and noticed 2 apparently-easy fixes, so I pushed a branch to https://code.launchpad.net/~tom-roche/python-mode/improve-INSTALLATION-comment-and-custom-strings All changes are to python-mode.el: `diff -u` > @@ -54,15 +54,22 @@ > > ;; To install, just drop this file into a directory on your load-path and > ;; byte-compile it. To set up Emacs to automatically edit files ending in > -;; ".py" using python-mode add the following to your ~/.emacs file (GNU > -;; Emacs) or ~/.xemacs/init.el file (XEmacs): > +;; ".py" using python-mode, add to your emacs init file > +;; > +;; GNU Emacs: ~/.emacs, ~/.emacs.el, or ~/.emacs.d/init.el > +;; > +;; XEmacs: ~/.xemacs/init.el > +;; > +;; the following code: > +;; > ;; (setq auto-mode-alist (cons '("\\.py$" . python-mode) auto-mode-alist)) > ;; (setq interpreter-mode-alist (cons '("python" . python-mode) > ;; interpreter-mode-alist)) > ;; (autoload 'python-mode "python-mode" "Python editing mode." t) > ;; > ;; In XEmacs syntax highlighting should be enabled automatically. In GNU > -;; Emacs you may have to add these lines to your ~/.emacs file: > +;; Emacs you may have to add these lines to your init file: > +;; > ;; (global-font-lock-mode t) > ;; (setq font-lock-maximum-decoration t) > > @@ -381,12 +388,12 @@ > "for" "if" "while" "finally" "try" > "with" > ) > - "*Keywords that can be hiden by hide-show" > + "*Keywords that can be hidden by hide-show" > :type '(repeat string) > :group 'python) > > (defcustom py-hide-show-hide-docstrings t > - "*Controls if doc strings can be hiden by hide-show" > + "*Controls if doc strings can be hidden by hide-show" > :type 'boolean > :group 'python) Perhaps this will be useful. As I know little about your procedures, had never used bzr at all until yesterday, and had never done a bzr commit until 10 min ago, please let me know if anything needs done better/ correctly. HTH, Tom Roche From Tom_Roche at pobox.com Tue Mar 16 22:34:51 2010 From: Tom_Roche at pobox.com (Tom Roche) Date: Tue, 16 Mar 2010 17:34:51 -0400 Subject: [Python-mode] [PDEE] CEDET integration with python-mode.el? In-Reply-To: <87k4tccooo.fsf@pobox.com> References: <87k4tccooo.fsf@pobox.com> <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> Message-ID: <87wrxcar2c.fsf@pobox.com> Have you tried to use CEDET with python.el? If so, how did it work? Why I ask: I'm a longtime (though not expert) emacs user (currently using GNU Emacs 23.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.0) of 2009-09-27 on crested, modified by Debian aka ubuntu karmic package=emacs-snapshot), new python coder, and former cperl and JDEE http://jdee.sourceforge.net/ user. I'd like to have a python development environment for emacs (PDEE) as useful as JDEE. Given my version of emacs, I got, and am trying out, python.el, but I'm also trying out python-mode.el. It's working well enough, but I'd really appreciate features like smart completion. I'll try setting up pycomplete, but note pycomplete.py > (untried w/ GNU Emacs so far) ... > This is unlikely to be done the way Emacs completion ought to be done, It Seems To Me (quite possibly naively) that the best/easiest way to get smarter completion particularly, and several more services besides, is to use CEDET http://cedet.sourceforge.net/ (as does JDEE). So I'm wondering if you (collectively) or someone you know has tried that, how it worked, and (if it worked) what init.el config code was required. TIA, Tom Roche From rileyrg at googlemail.com Wed Mar 17 12:30:17 2010 From: rileyrg at googlemail.com (Richard Riley) Date: Wed, 17 Mar 2010 12:30:17 +0100 Subject: [Python-mode] Hey In-Reply-To: <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> (Deniz Dogan's message of "Wed, 17 Mar 2010 12:03:24 +0100") References: <20100314153324.2d5d12c5@heresy.wooz.org> <20100316165506.69a2b298@heresy> <7b501d5c1003170209p55463b8bx33fd32a52c19e81d@mail.gmail.com> <4BA0A12F.2030104@online.de> <7b501d5c1003170403m73b9f3c5y82453694f0cef6da@mail.gmail.com> Message-ID: Deniz Dogan writes: > 2010/3/17 Andreas Roehler : >> Deniz Dogan wrote: >>> 2010/3/16 Barry Warsaw : >>>> On Mar 16, 2010, at 09:39 AM, m h wrote: >>>> >>>>> On this note, it might be nice to create a wiki page (python.el vs >>>>> python-mode.el) elaborating the different features found in each.... >>>> Like this one: >>>> >>>> http://www.emacswiki.org/emacs/PythonMode >>>> >>>> Could use lots of clean up though. >>>> -Barry >>>> >>> >>> I think the main problem about that wiki entry is that it's on >>> EmacsWiki. Most EmacsWiki entries look just like that, everything ends >>> up a discussion board and/or bunch of recipes for unrelated features. >>> >> >> Isn't that a feature rather characteristic of all wikis? >> >> EmacsWiki does very well in relation, provides a lot of useful stuff IMO. >> Download facility is excellent. >> > > EmacsWiki _is_ useful, I use it all the time. I'm just saying there > are huge problems with mixing discussion and actual information on one > page, especially as there is absolutely no visual indication about > what's what. In relation to what do you think that EmacsWiki does very > well? The Wiki is very useful. It is also a mess in many places. The nature of the beast is that people tend to append rather than correct and restructure. Many people, myself included, put up what works for them but do not have the depth of knowledge or the confidence to remove other, possibly out of date or plain incorrect, information. So yes, I agree with you ;) From deniz.a.m.dogan at gmail.com Thu Mar 18 16:19:43 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Thu, 18 Mar 2010 16:19:43 +0100 Subject: [Python-mode] simple comment/string-tweak branch In-Reply-To: <87bpeoqaoc.fsf@pobox.com> References: <87bpeoqaoc.fsf@pobox.com> Message-ID: <7b501d5c1003180819s71972d95x23955a5506d499a8@mail.gmail.com> 2010/3/16 Tom Roche : > > Preparatory to an upcoming post on using/improving python-mode, I > looked @ the code and noticed 2 apparently-easy fixes, so I pushed a > branch to > > https://code.launchpad.net/~tom-roche/python-mode/improve-INSTALLATION-comment-and-custom-strings > > All changes are to python-mode.el: > > `diff -u` >> @@ -54,15 +54,22 @@ >> >> ?;; To install, just drop this file into a directory on your load-path and >> ?;; byte-compile it. ?To set up Emacs to automatically edit files ending in >> -;; ".py" using python-mode add the following to your ~/.emacs file (GNU >> -;; Emacs) or ~/.xemacs/init.el file (XEmacs): >> +;; ".py" using python-mode, add to your emacs init file >> +;; >> +;; GNU Emacs: ~/.emacs, ~/.emacs.el, or ~/.emacs.d/init.el >> +;; >> +;; XEmacs: ~/.xemacs/init.el >> +;; >> +;; the following code: >> +;; >> ?;; ? ?(setq auto-mode-alist (cons '("\\.py$" . python-mode) auto-mode-alist)) >> ?;; ? ?(setq interpreter-mode-alist (cons '("python" . python-mode) >> ?;; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? interpreter-mode-alist)) >> ?;; ? ?(autoload 'python-mode "python-mode" "Python editing mode." t) >> ?;; >> ?;; In XEmacs syntax highlighting should be enabled automatically. ?In GNU >> -;; Emacs you may have to add these lines to your ~/.emacs file: >> +;; Emacs you may have to add these lines to your init file: >> +;; >> ?;; ? ?(global-font-lock-mode t) >> ?;; ? ?(setq font-lock-maximum-decoration t) >> >> @@ -381,12 +388,12 @@ >> ? ? ?"for" ? ? ?"if" ? ? "while" ? "finally" "try" >> ? ? ?"with" >> ? ? ?) >> - ?"*Keywords that can be hiden by hide-show" >> + ?"*Keywords that can be hidden by hide-show" >> ? ?:type '(repeat string) >> ? ?:group 'python) >> >> ?(defcustom py-hide-show-hide-docstrings t >> - ?"*Controls if doc strings can be hiden by hide-show" >> + ?"*Controls if doc strings can be hidden by hide-show" >> ? ?:type 'boolean >> ? ?:group 'python) > > Perhaps this will be useful. As I know little about your procedures, had > never used bzr at all until yesterday, and had never done a bzr commit > until 10 min ago, please let me know if anything needs done better/ > correctly. > > HTH, Tom Roche > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > While we are already updating documentation, could someone change the instructions to use `add-to-list' instead of using `setq' in combination with `cons'? I'm not sure when `add-to-list' was added to Emacs/XEmacs, but I'm pretty sure it's "ancient enough" by now. Someone should also change the $ in the first regex to \\'. Not a diff, as I don't have a diff program installed, but: ;; To install, just drop this file into a directory on your load-path and ;; byte-compile it. To set up Emacs to automatically edit files ending in ;; ".py" using python-mode add the following to your ~/.emacs file (GNU ;; Emacs) or ~/.xemacs/init.el file (XEmacs): ;; ;; (add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode)) ;; (add-to-list 'interpreter-mode-alist '("python" . python-mode)) ;; (autoload 'python-mode "python-mode" "Python editing mode." t) ;; ;; In XEmacs syntax highlighting should be enabled automatically. In GNU ;; Emacs you may have to add these lines to your ~/.emacs file: ;; ;; (global-font-lock-mode t) ;; (setq font-lock-maximum-decoration t) Cheers, Deniz Dogan From deniz.a.m.dogan at gmail.com Thu Mar 18 20:22:39 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Thu, 18 Mar 2010 20:22:39 +0100 Subject: [Python-mode] Don't bind C-c C-h Message-ID: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> Please, don't bind C-c C-h to anything. This prevents people from viewing all the bindings that start with C-c, which C-c C-h would normally display. -- Deniz Dogan From andreas.roehler at online.de Thu Mar 18 21:50:32 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Thu, 18 Mar 2010 21:50:32 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> Message-ID: <4BA29218.30005@online.de> Deniz Dogan wrote: > Please, don't bind C-c C-h to anything. This prevents people from > viewing all the bindings that start with C-c, which C-c C-h would > normally display. > Hi Deniz, it may help, if you write your suggestion into the bug-tracker. So it doesn't get lost. https://bugs.launchpad.net/python-mode When reporting, please explain a little bit more the reasons. What's there as mentioned normally for you? Exists some coding convention which contradicts? Thanks taking part Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From deniz.a.m.dogan at gmail.com Thu Mar 18 21:57:56 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Thu, 18 Mar 2010 21:57:56 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <4BA29218.30005@online.de> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> Message-ID: <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> 2010/3/18 Andreas Roehler : > Deniz Dogan wrote: >> Please, don't bind C-c C-h to anything. This prevents people from >> viewing all the bindings that start with C-c, which C-c C-h would >> normally display. >> > > Hi Deniz, > > it may help, if you write your suggestion into the bug-tracker. So it doesn't get lost. > > https://bugs.launchpad.net/python-mode > > When reporting, please explain a little bit more the reasons. What's there as mentioned normally for you? > Exists some coding convention which contradicts? > > Thanks taking part > Would someone mind reporting the issue there for me? I don't plan on using Launchpad any time soon other than for this. If anyone gets around to doing that, you can use the following description of the problem: I'm not sure there is an actual convention that says one shouldn't use C-h in a key sequence. However, I often use C-h as a "suffix" key to find out more about key sequences that start out a certain way. You can try this by hitting e.g. "C-x n C-h", which should give you: C-x n d narrow-to-defun C-x n n narrow-to-region C-x n p narrow-to-page C-x n w widen I use this feature quite often in Emacs and I'm sure some other people do it to. Of course, one can use "C-h m" to find out more about the mode-specific key bindings, but there is still use for C-h as a suffix, as it shows you _all_ of the bindings that start with a particular key sequence. -- Deniz Dogan From andreas.roehler at online.de Fri Mar 19 07:27:37 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 19 Mar 2010 07:27:37 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> Message-ID: <4BA31959.4030503@online.de> Deniz Dogan wrote: > 2010/3/18 Andreas Roehler : >> Deniz Dogan wrote: >>> Please, don't bind C-c C-h to anything. This prevents people from >>> viewing all the bindings that start with C-c, which C-c C-h would >>> normally display. >>> >> Hi Deniz, >> >> it may help, if you write your suggestion into the bug-tracker. So it doesn't get lost. >> >> https://bugs.launchpad.net/python-mode >> >> When reporting, please explain a little bit more the reasons. What's there as mentioned normally for you? >> Exists some coding convention which contradicts? >> >> Thanks taking part >> > > Would someone mind reporting the issue there for me? I don't plan on > using Launchpad any time soon other than for this. If anyone gets > around to doing that, you can use the following description of the > problem: > > I'm not sure there is an actual convention that says one shouldn't use > C-h in a key sequence. However, I often use C-h as a "suffix" key to > find out more about key sequences that start out a certain way. You > can try this by hitting e.g. "C-x n C-h", which should give you: > > C-x n d narrow-to-defun > C-x n n narrow-to-region > C-x n p narrow-to-page > C-x n w widen > > I use this feature quite often in Emacs and I'm sure some other people > do it to. Of course, one can use "C-h m" to find out more about the > mode-specific key bindings, but there is still use for C-h as a > suffix, as it shows you _all_ of the bindings that start with a > particular key sequence. > You mentioned a binding starting with C-c, not with C-x as your example shows now. So the matter is done? From rohan.nicholls at googlemail.com Fri Mar 19 10:13:20 2010 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Fri, 19 Mar 2010 10:13:20 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <4BA31959.4030503@online.de> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> Message-ID: I am going to weigh in here. Denis is absolutely correct. It is an official binding and convention in emacs, and I believe xemacs. C-h is sacred. It has a bunch of functionality behind it tied in with prefix keys. This means that in creating a map, and binding it to a prefix key, when you hit: , C-h it will list all the bindings for that key's map. As a very practical example, I use F5 for various org-mode functionality. This is accomplished by defining F5 as a prefix key, and binding a keymap I populated with various bindings to that key. Now whenever I forget (frequently) what I had bound to what I just hit F5,C-h and all the bindings are displayed. And this holds for C-c. If I hit C-c,C-h it is because I want to see what the bindings are for the current mode. I and many other emacs users would be seriously thrown, not to say upset, if this functionality was changed. The C-h binding is very important for discoverability, and I think it is a very, very bad idea to bind it to anything. Just my 2 cents worth. Thanks, Rohan On Fri, Mar 19, 2010 at 7:27 AM, Andreas Roehler wrote: > Deniz Dogan wrote: >> 2010/3/18 Andreas Roehler : >>> Deniz Dogan wrote: >>>> Please, don't bind C-c C-h to anything. This prevents people from >>>> viewing all the bindings that start with C-c, which C-c C-h would >>>> normally display. >>>> >>> Hi Deniz, >>> >>> it may help, if you write your suggestion into the bug-tracker. So it doesn't get lost. >>> >>> https://bugs.launchpad.net/python-mode >>> >>> When reporting, please explain a little bit more the reasons. What's there as mentioned normally for you? >>> Exists some coding convention which contradicts? >>> >>> Thanks taking part >>> >> >> Would someone mind reporting the issue there for me? I don't plan on >> using Launchpad any time soon other than for this. If anyone gets >> around to doing that, you can use the following description of the >> problem: >> >> I'm not sure there is an actual convention that says one shouldn't use >> C-h in a key sequence. However, I often use C-h as a "suffix" key to >> find out more about key sequences that start out a certain way. You >> can try this by hitting e.g. "C-x n C-h", which should give you: >> >> ?C-x n d ? ? ? ? narrow-to-defun >> C-x n n ? ? ? ? narrow-to-region >> C-x n p ? ? ? ? narrow-to-page >> C-x n w ? ? ? ? widen >> >> I use this feature quite often in Emacs and I'm sure some other people >> do it to. Of course, one can use "C-h m" to find out more about the >> mode-specific key bindings, but there is still use for C-h as a >> suffix, as it shows you _all_ of the bindings that start with a >> particular key sequence. >> > > You mentioned a binding starting with C-c, not with C-x as your example shows now. > So the matter is done? > > > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From reinout at vanrees.org Fri Mar 19 09:54:17 2010 From: reinout at vanrees.org (Reinout van Rees) Date: Fri, 19 Mar 2010 09:54:17 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <4BA31959.4030503@online.de> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> Message-ID: On 03/19/2010 07:27 AM, Andreas Roehler wrote: > Deniz Dogan wrote: >> 2010/3/18 Andreas Roehler: >>> Deniz Dogan wrote: >>>> Please, don't bind C-c C-h to anything. This prevents people from >>>> viewing all the bindings that start with C-c, which C-c C-h would >>>> normally display. >>>> >>> Hi Deniz, >>> >>> it may help, if you write your suggestion into the bug-tracker. So it doesn't get lost. >>> >>> https://bugs.launchpad.net/python-mode >>> >>> When reporting, please explain a little bit more the reasons. What's there as mentioned normally for you? >>> Exists some coding convention which contradicts? >>> >>> Thanks taking part >>> >> >> Would someone mind reporting the issue there for me? I don't plan on >> using Launchpad any time soon other than for this. If anyone gets >> around to doing that, you can use the following description of the >> problem: >> >> I'm not sure there is an actual convention that says one shouldn't use >> C-h in a key sequence. However, I often use C-h as a "suffix" key to >> find out more about key sequences that start out a certain way. You >> can try this by hitting e.g. "C-x n C-h", which should give you: >> >> C-x n d narrow-to-defun >> C-x n n narrow-to-region >> C-x n p narrow-to-page >> C-x n w widen >> >> I use this feature quite often in Emacs and I'm sure some other people >> do it to. Of course, one can use "C-h m" to find out more about the >> mode-specific key bindings, but there is still use for C-h as a >> suffix, as it shows you _all_ of the bindings that start with a >> particular key sequence. >> > > You mentioned a binding starting with C-c, not with C-x as your example shows now. > So the matter is done? Nope. What he actually meant was "don't use ctrl-h in a binding". Regardless of whether it is ctrl-c or ctrl-x or ctrl-?. Ctrl-h is the standard emacs key you can press anywhere in a sequence of alt/ctrl commands to get a description of everything that's possible there. ctrl-c ctrl-h: show everything I can do after ctrl-c here. ctrl-x v ctrl-h: what where those version control commands again... (What I don't know is where in python mode he found a ctrl-h binding, btw). Reinout -- Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" From deniz.a.m.dogan at gmail.com Fri Mar 19 10:57:56 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Fri, 19 Mar 2010 10:57:56 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> Message-ID: <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> 2010/3/19 Reinout van Rees : > On 03/19/2010 07:27 AM, Andreas Roehler wrote: >> >> Deniz Dogan wrote: >>> >>> 2010/3/18 Andreas Roehler: >>>> >>>> Deniz Dogan wrote: >>>>> >>>>> Please, don't bind C-c C-h to anything. This prevents people from >>>>> viewing all the bindings that start with C-c, which C-c C-h would >>>>> normally display. >>>>> >>>> Hi Deniz, >>>> >>>> it may help, if you write your suggestion into the bug-tracker. So it >>>> doesn't get lost. >>>> >>>> https://bugs.launchpad.net/python-mode >>>> >>>> When reporting, please explain a little bit more the reasons. What's >>>> there as mentioned normally for you? >>>> Exists some coding convention which contradicts? >>>> >>>> Thanks taking part >>>> >>> >>> Would someone mind reporting the issue there for me? I don't plan on >>> using Launchpad any time soon other than for this. If anyone gets >>> around to doing that, you can use the following description of the >>> problem: >>> >>> I'm not sure there is an actual convention that says one shouldn't use >>> C-h in a key sequence. However, I often use C-h as a "suffix" key to >>> find out more about key sequences that start out a certain way. You >>> can try this by hitting e.g. "C-x n C-h", which should give you: >>> >>> ?C-x n d ? ? ? ? narrow-to-defun >>> C-x n n ? ? ? ? narrow-to-region >>> C-x n p ? ? ? ? narrow-to-page >>> C-x n w ? ? ? ? widen >>> >>> I use this feature quite often in Emacs and I'm sure some other people >>> do it to. Of course, one can use "C-h m" to find out more about the >>> mode-specific key bindings, but there is still use for C-h as a >>> suffix, as it shows you _all_ of the bindings that start with a >>> particular key sequence. >>> >> >> You mentioned a binding starting with C-c, not with C-x as your example >> shows now. >> So the matter is done? > > Nope. What he actually meant was "don't use ctrl-h in a binding". Regardless > of whether it is ctrl-c or ctrl-x or ctrl-?. > > Ctrl-h is the standard emacs key you can press anywhere in a sequence of > alt/ctrl commands to get a description of everything that's possible there. > > ctrl-c ctrl-h: show everything I can do after ctrl-c here. > > ctrl-x v ctrl-h: what where those version control commands again... > > > (What I don't know is where in python mode he found a ctrl-h binding, btw). > > Reinout > In python-mode.el with py-version "5.1.0+" whatever that means: Line 692: (define-key py-mode-map "\C-c\C-h" 'py-help-at-point) -- Deniz Dogan From reinout at vanrees.org Fri Mar 19 11:07:29 2010 From: reinout at vanrees.org (Reinout van Rees) Date: Fri, 19 Mar 2010 11:07:29 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> Message-ID: On 03/19/2010 10:57 AM, Deniz Dogan wrote: > 2010/3/19 Reinout van Rees: >> >> (What I don't know is where in python mode he found a ctrl-h binding, btw). >> > > In python-mode.el with py-version "5.1.0+" whatever that means: > > Line 692: > (define-key py-mode-map "\C-c\C-h" 'py-help-at-point) Ouch. Yes, that's evil. It breaks a major emacs convention. ctrl-h *is* sadly the logical key for some help-related function. Would "ctrl-c h" be an alternative? Reinout -- Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" From skip at pobox.com Fri Mar 19 11:11:38 2010 From: skip at pobox.com (skip at pobox.com) Date: Fri, 19 Mar 2010 05:11:38 -0500 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> Message-ID: <19363.19930.831428.619523@montanaro.dyndns.org> Deniz> In python-mode.el with py-version "5.1.0+" whatever that means: Deniz> Line 692: Deniz> (define-key py-mode-map "\C-c\C-h" 'py-help-at-point) Yeah, that was probably my doing a long time ago. Skip From andreas.roehler at online.de Fri Mar 19 12:55:02 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Fri, 19 Mar 2010 12:55:02 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <19363.19930.831428.619523@montanaro.dyndns.org> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <19363.19930.831428.619523@montanaro.dyndns.org> Message-ID: <4BA36616.8030605@online.de> skip at pobox.com wrote: > Deniz> In python-mode.el with py-version "5.1.0+" whatever that means: > > Deniz> Line 692: > Deniz> (define-key py-mode-map "\C-c\C-h" 'py-help-at-point) > > Yeah, that was probably my doing a long time ago. > > Skip > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > Thanks Deniz, thanks all, made a bug report. https://bugs.launchpad.net/python-mode/+bug/541833 Any suggestions how to replace the key? Andreas From deniz.a.m.dogan at gmail.com Fri Mar 19 12:54:08 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Fri, 19 Mar 2010 12:54:08 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> Message-ID: <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> 2010/3/19 Reinout van Rees : > On 03/19/2010 10:57 AM, Deniz Dogan wrote: >> >> 2010/3/19 Reinout van Rees: >>> >>> (What I don't know is where in python mode he found a ctrl-h binding, >>> btw). >>> >> >> In python-mode.el with py-version "5.1.0+" whatever that means: >> >> Line 692: >> ? (define-key py-mode-map "\C-c\C-h" ?'py-help-at-point) > > Ouch. ?Yes, that's evil. ?It breaks a major emacs convention. > > ctrl-h *is* sadly the logical key for some help-related function. ?Would > "ctrl-c h" be an alternative? > 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. C-c ? would be okay, but that's already bound to py-describe-mode. Maybe C-c C-? would work, but I'm not sure how that is recognized by terminals. -- Deniz Dogan From skip at pobox.com Fri Mar 19 14:09:24 2010 From: skip at pobox.com (skip at pobox.com) Date: Fri, 19 Mar 2010 08:09:24 -0500 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <7b501d5c1003190454q2c851565t5a787693cb511ee0@mail.gmail.com> 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: <19363.30596.600076.209455@montanaro.dyndns.org> >>>>> "Deniz" == Deniz Dogan writes: Deniz> Maybe C-c C-? would work, but I'm not sure how that is recognized Deniz> by terminals. Not at all on my Sun (Intel) box running Solaris 10 with a Dell keyboard. It maps to C-c ?... S From barry at python.org Fri Mar 19 15:30:54 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 10:30:54 -0400 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> Message-ID: <20100319103054.44ae7666@heresy> On Mar 19, 2010, at 09:54 AM, Reinout van Rees wrote: >ctrl-c ctrl-h: show everything I can do after ctrl-c here. C-c C-h is not bound to anything in c-mode or conf-mode AFAICT. So, if it's not a standard Emacs key binding, does that mean it's explicitly reserved for users by Emacs? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Fri Mar 19 15:34:08 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 10:34:08 -0400 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> Message-ID: <20100319103408.39a53ba6@heresy> On Mar 19, 2010, at 11:07 AM, Reinout van Rees wrote: >> Line 692: >> (define-key py-mode-map "\C-c\C-h" 'py-help-at-point) > >Ouch. Yes, that's evil. It breaks a major emacs convention. > >ctrl-h *is* sadly the logical key for some help-related function. Would >"ctrl-c h" be an alternative? Hi Reinout. Is that defined in an Emacs Lisp standard somewhere? I'm having a hard time finding /any/ other mode where C-c C-h is bound to anything (mail-mode and shell-mode are two others I've checked). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Fri Mar 19 15:38:51 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 10:38:51 -0400 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> Message-ID: <20100319103851.5812de36@heresy> On Mar 19, 2010, at 10:13 AM, Rohan Nicholls wrote: >The C-h binding is very important for discoverability, and I think it >is a very, very bad idea to bind it to anything. If we /do/ change it, may I suggest C-c C-e? 'e' being a mnemonic for 'explain', and C-c C-e is currently unused in python-mode. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From reinout at vanrees.org Fri Mar 19 15:58:49 2010 From: reinout at vanrees.org (Reinout van Rees) Date: Fri, 19 Mar 2010 15:58:49 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <20100319103408.39a53ba6@heresy> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> Message-ID: On 03/19/2010 03:34 PM, Barry Warsaw wrote: > On Mar 19, 2010, at 11:07 AM, Reinout van Rees wrote: > >> ctrl-h *is* sadly the logical key for some help-related function. Would >> "ctrl-c h" be an alternative? > > Hi Reinout. Is that defined in an Emacs Lisp standard somewhere? I'm having > a hard time finding /any/ other mode where C-c C-h is bound to anything > (mail-mode and shell-mode are two others I've checked). Hm. It is apparently not as clear-cut as I always took it to be. Emacs' info (for instance http://www.chemie.fu-berlin.de/chemnet/use/info/emacs/emacs_11.html ): C-h or F1 means "help" in various other contexts as well. For example, in query-replace, it describes the options available. After a prefix key, it displays a list of the alternatives that can follow the prefix key. (A few prefix keys don't support this because they define other meanings for C-h.) So it *is* apparently OK to use ctrl-h in other meanings! But ctrl-c ctrl-h seems to work in every mode I just tested it on: it gives a nice overview of possible keys. I know most basic keybindings, but the particulars of all those major modes... That's what ctrl-c ctrl-h is for. Similarly the version control (minor?) mode: ctrl-x v ctrl-h ("what was the annotate/blame/praise command again?") And I just discovered that the "emacs starter kit" I'm using has re-bound ctrl-x ctrl-h to some open-a-url function, sigh :-) Reinout -- Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" From barry at python.org Fri Mar 19 16:21:16 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 11:21:16 -0400 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> Message-ID: <20100319112116.46b6523e@heresy> On Mar 19, 2010, at 03:58 PM, Reinout van Rees wrote: >Hm. It is apparently not as clear-cut as I always took it to be. Emacs' >info (for instance >http://www.chemie.fu-berlin.de/chemnet/use/info/emacs/emacs_11.html ): > > C-h or F1 means "help" in various other contexts as well. For > example, in query-replace, it describes the options available. > After a prefix key, it displays a list of the alternatives that > can follow the prefix key. (A few prefix keys don't support this > because they define other meanings for C-h.) > >So it *is* apparently OK to use ctrl-h in other meanings! :) >But ctrl-c ctrl-h seems to work in every mode I just tested it on: it >gives a nice overview of possible keys. I'm not opposed to moving it and leaving C-c C-h for common functionality. I know how much it hurts when modes break your DNA-ingrained assumptions (hello, gud?!). Any objections to C-c C-e? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From reinout at vanrees.org Fri Mar 19 17:12:47 2010 From: reinout at vanrees.org (Reinout van Rees) Date: Fri, 19 Mar 2010 17:12:47 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <20100319112116.46b6523e@heresy> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> <20100319112116.46b6523e@heresy> Message-ID: On 03/19/2010 04:21 PM, Barry Warsaw wrote: > > Any objections to C-c C-e? None at all. That e-for-explain you mentioned sounds fine. Reinout -- Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org Programmer at http://www.nelen-schuurmans.nl "Military engineers build missiles. Civil engineers build targets" From barry at python.org Fri Mar 19 17:30:08 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 12:30:08 -0400 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> <20100319112116.46b6523e@heresy> Message-ID: <20100319123008.3bb082fe@heresy> On Mar 19, 2010, at 05:12 PM, Reinout van Rees wrote: >On 03/19/2010 04:21 PM, Barry Warsaw wrote: >> >> Any objections to C-c C-e? > >None at all. That e-for-explain you mentioned sounds fine. Cool. Bug updated. -B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From skip at pobox.com Fri Mar 19 18:27:41 2010 From: skip at pobox.com (skip at pobox.com) Date: Fri, 19 Mar 2010 12:27:41 -0500 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <20100319103851.5812de36@heresy> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <20100319103851.5812de36@heresy> Message-ID: <19363.46093.33242.116216@montanaro.dyndns.org> >> The C-h binding is very important for discoverability, and I think it >> is a very, very bad idea to bind it to anything. Barry> If we /do/ change it, may I suggest C-c C-e? 'e' being a Barry> mnemonic for 'explain', and C-c C-e is currently unused in Barry> python-mode. Is there any other programming mode with something akin to py-help-at-point? If so, what binding(s) do they use? S From georg at python.org Fri Mar 19 18:34:33 2010 From: georg at python.org (Georg Brandl) Date: Fri, 19 Mar 2010 18:34:33 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> Message-ID: <4BA3B5A9.9020305@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 19.03.2010 15:58, schrieb Reinout van Rees: > On 03/19/2010 03:34 PM, Barry Warsaw wrote: >> On Mar 19, 2010, at 11:07 AM, Reinout van Rees wrote: >> >>> ctrl-h *is* sadly the logical key for some help-related function. Would >>> "ctrl-c h" be an alternative? >> >> Hi Reinout. Is that defined in an Emacs Lisp standard somewhere? I'm having >> a hard time finding /any/ other mode where C-c C-h is bound to anything >> (mail-mode and shell-mode are two others I've checked). > > Hm. It is apparently not as clear-cut as I always took it to be. Emacs' > info (for instance > http://www.chemie.fu-berlin.de/chemnet/use/info/emacs/emacs_11.html ): > > C-h or F1 means "help" in various other contexts as well. For > example, in query-replace, it describes the options available. > After a prefix key, it displays a list of the alternatives that > can follow the prefix key. (A few prefix keys don't support this > because they define other meanings for C-h.) > > So it *is* apparently OK to use ctrl-h in other meanings! > > But ctrl-c ctrl-h seems to work in every mode I just tested it on: it > gives a nice overview of possible keys. > > I know most basic keybindings, but the particulars of all those major > modes... That's what ctrl-c ctrl-h is for. FWIW, I agree. Binding C-h is almost as ugly as binding C-g. C-c C-e sounds nice. Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkujtakACgkQN9GcIYhpnLAQIACeL1NhRMQbaDW/tTx3yg35tpyL sSsAn1KHJKJnq0gL6C5xglRDusiPOBw+ =T6Kz -----END PGP SIGNATURE----- From barry at python.org Sat Mar 20 01:08:36 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 20:08:36 -0400 Subject: [Python-mode] simple comment/string-tweak branch In-Reply-To: <87bpeoqaoc.fsf@pobox.com> References: <87bpeoqaoc.fsf@pobox.com> Message-ID: <20100319200836.6debcd52@heresy> On Mar 16, 2010, at 04:22 PM, Tom Roche wrote: >Perhaps this will be useful. As I know little about your procedures, had >never used bzr at all until yesterday, and had never done a bzr commit >until 10 min ago, please let me know if anything needs done better/ >correctly. I think you did it just about perfectly. I've reviewed and accepted the merge proposal. Maybe Andreas would like to merge and push it? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Sat Mar 20 01:11:12 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 20:11:12 -0400 Subject: [Python-mode] simple comment/string-tweak branch In-Reply-To: <7b501d5c1003180819s71972d95x23955a5506d499a8@mail.gmail.com> References: <87bpeoqaoc.fsf@pobox.com> <7b501d5c1003180819s71972d95x23955a5506d499a8@mail.gmail.com> Message-ID: <20100319201112.6fe80d07@heresy> On Mar 18, 2010, at 04:19 PM, Deniz Dogan wrote: >While we are already updating documentation, could someone change the >instructions to use `add-to-list' instead of using `setq' in >combination with `cons'? I'm not sure when `add-to-list' was added to >Emacs/XEmacs, but I'm pretty sure it's "ancient enough" by now. >Someone should also change the $ in the first regex to \\'. +1 if these work with current versions of Emacs and XEmacs. I no longer have the latter to test with. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Sat Mar 20 02:38:23 2010 From: barry at python.org (Barry Warsaw) Date: Fri, 19 Mar 2010 21:38:23 -0400 Subject: [Python-mode] plan for emacs python tooling (esp python.el, python-mode.el)? In-Reply-To: <4B9F6D69.4020909@siege-engine.com> References: <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> Message-ID: <20100319213823.6e5e89e6@heresy> On Mar 16, 2010, at 07:37 AM, Eric M. Ludlam wrote: >Exuberent ctags supports python (though I don't know by how much), and >adding support in the CEDET/Semantic exuberant ctags support wouldn't be >too hard. Likely something like the patch attached. exuberent-tags is a separate package on Ubuntu, and it supports Python well. Actually too well IMO. I don't like variable or import tags so something like --python-kinds=-vi [*] should work pretty well. -Barry [*] ironic, ain't it? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From lists at onerussian.com Sat Mar 20 03:22:01 2010 From: lists at onerussian.com (Yaroslav Halchenko) Date: Fri, 19 Mar 2010 22:22:01 -0400 Subject: [Python-mode] [PDEE] CEDET integration with python-mode.el? In-Reply-To: <87wrxcar2c.fsf@pobox.com> References: <87k4tccooo.fsf@pobox.com> <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> <87wrxcar2c.fsf@pobox.com> Message-ID: <20100320022201.GS1205@onerussian.com> On Tue, 16 Mar 2010, Tom Roche wrote: > It Seems To Me (quite possibly naively) that the best/easiest way to > get smarter completion particularly, and several more services > besides, is to use CEDET or may be (citing my post earlier in this list): Ipython + python-mode + python-ropemacs + pylint + flymake + outline make emacs very well featured for Python mode development (completions, documentation lookup, jump to definition, etc). You might look into my messy .emacs setup [1] or excerpt from it, which I placed into pymvpa project [2], on how to make such combination work nicely. There is an ongoing discussion in python-mode mailing list [3] regarding possible merge of python.el (shipped with GNU emacs) and python-mode.el (separate project which originated at python.org) [1] http://git.onerussian.com/?p=etc/emacs.git;a=summary [2] http://git.debian.org/?p=pkg-exppsy/pymvpa.git;a=blob;f=doc/misc/emacs;h=42876c90a36ce73c34fc20408bfea44657e8a07a;hb=46624cd2bbc2f864621b7bd48673b44dc22af3e5 [3] http://mail.python.org/pipermail/python-mode/2009-February/thread.html -- .-. =------------------------------ /v\ ----------------------------= Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User ^^-^^ [175555] From rohan.nicholls at googlemail.com Sat Mar 20 20:47:15 2010 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Sat, 20 Mar 2010 20:47:15 +0100 Subject: [Python-mode] [PDEE] CEDET integration with python-mode.el? In-Reply-To: <20100320022201.GS1205@onerussian.com> References: <87k4tccooo.fsf@pobox.com> <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> <87wrxcar2c.fsf@pobox.com> <20100320022201.GS1205@onerussian.com> Message-ID: On Sat, Mar 20, 2010 at 3:22 AM, Yaroslav Halchenko wrote: > > On Tue, 16 Mar 2010, Tom Roche wrote: > >> It Seems To Me (quite possibly naively) that the best/easiest way to >> get smarter completion particularly, and several more services >> besides, is to use CEDET > or may be (citing my post earlier in this list): > > Ipython + python-mode + python-ropemacs + pylint + flymake + outline > make emacs very well featured for Python mode development > (completions, documentation lookup, jump to definition, etc). You might > look into my messy .emacs setup [1] or excerpt from it, which I placed > into pymvpa project [2], on how to make such combination work nicely. I have also used such a setup, and it has a lot to offer, but I found that it really dies on you when you work with big projects. I think it is the rope library, because working on a zope project or the large code base I was working on at my last job, and getting a completion or saving a file would make everything really, really slow, or worse, send rope into a complete tailspin. I would love to see python and cedet come together, as there is so much functionality out of the box with cedet, while with rope etc. the project browsing is seriously lacking, as was semantic code completion. As fabulous as ipython is, it only understands what it has processed, and has problems (not its fault, this is something that lies deep in the python interpretor itself) updating the object environment, so updating functions, methods and classes with ipython does not necessarily update the current objects, in fact more often than not doesn't. I would also like to add; there is no really good python development tools, and if pdee came about combining the cedet functionality with good debugging integration, it would be ahead of current python ides (IMHO). About the debugging, I was thinking that maybe creating an emacs frontend to rpdb (command line version of the winpdb debugger), which seems to handle threading as well if not better than anyone else. Pdb falls down horribly when dealing with multi-threaded applications such as a wx-python or zope app. One thing that is really nice about rope, is that it does handle refactoring really well, in fact it had a lot of features that wingide could not match (I have used both), but maybe cedet has these facilities. Anyway, that was my thinking. Do I have the slightest clue where to start to make this happen? Nope. But I am still working in python, and at the moment with zope, so I need to find or help build a solution, and if it uses emacs as its frontend so much the better. Thanks, Rohan From lists at onerussian.com Sat Mar 20 23:35:35 2010 From: lists at onerussian.com (Yaroslav Halchenko) Date: Sat, 20 Mar 2010 18:35:35 -0400 Subject: [Python-mode] [PDEE] CEDET integration with python-mode.el? In-Reply-To: References: <87k4tccooo.fsf@pobox.com> <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> <87wrxcar2c.fsf@pobox.com> <20100320022201.GS1205@onerussian.com> Message-ID: <20100320223535.GU1205@onerussian.com> On Sat, 20 Mar 2010, Rohan Nicholls wrote: > > Ipython + python-mode + python-ropemacs + pylint + flymake + outline > > >...< > I have also used such a setup, and it has a lot to offer, but I found > that it really dies on you when you work with big projects. I think > >...< I had similar slowdown/cpu_intensive experience with some versions of pylint and more or less large projects but then it somehow became sane again (didn't check if any recent version changelog had any performance/dependecy_tracking improvements mentioned) > emacs frontend to rpdb (command line version of the winpdb debugger), > which seems to handle threading as well if not better than anyone > else. Pdb falls down horribly when dealing with multi-threaded > applications such as a wx-python or zope app. what about pydb (or even may be a new rewrite pydbgr ?) I bet Rocky (their author) who is also an emacs user might like to join the forces to provide adequate glue? (CCing him just in case... for the complete thread see http://mail.python.org/pipermail/python-mode/2010-March/000751.html -- .-. =------------------------------ /v\ ----------------------------= Keep in touch // \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User ^^-^^ [175555] From andreas.roehler at online.de Sun Mar 21 21:39:14 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 21 Mar 2010 21:39:14 +0100 Subject: [Python-mode] simple comment/string-tweak branch In-Reply-To: <20100319200836.6debcd52@heresy> References: <87bpeoqaoc.fsf@pobox.com> <20100319200836.6debcd52@heresy> Message-ID: <4BA683F2.3090408@online.de> Barry Warsaw wrote: > On Mar 16, 2010, at 04:22 PM, Tom Roche wrote: > >> Perhaps this will be useful. As I know little about your procedures, had >> never used bzr at all until yesterday, and had never done a bzr commit >> until 10 min ago, please let me know if anything needs done better/ >> correctly. > > I think you did it just about perfectly. I've reviewed and accepted the merge > proposal. Maybe Andreas would like to merge and push it? > > -Barry > > done From andreas.roehler at online.de Sun Mar 21 21:52:01 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Sun, 21 Mar 2010 21:52:01 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <20100319123008.3bb082fe@heresy> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> <20100319112116.46b6523e@heresy> <20100319123008.3bb082fe@heresy> Message-ID: <4BA686F1.3040703@online.de> Barry Warsaw wrote: > On Mar 19, 2010, at 05:12 PM, Reinout van Rees wrote: > >> On 03/19/2010 04:21 PM, Barry Warsaw wrote: >>> Any objections to C-c C-e? >> None at all. That e-for-explain you mentioned sounds fine. > > Cool. Bug updated. > -B > > Fix is here: lp:~a-roehler/python-mode/dont-bind-C-c-C-h-541833 Merge? Andreas From barry at python.org Sun Mar 21 22:43:53 2010 From: barry at python.org (Barry Warsaw) Date: Sun, 21 Mar 2010 17:43:53 -0400 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <4BA686F1.3040703@online.de> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> <20100319112116.46b6523e@heresy> <20100319123008.3bb082fe@heresy> <4BA686F1.3040703@online.de> Message-ID: <39DAB885-983B-4001-8DEC-FEFC2048E214@python.org> On Mar 21, 2010, at 4:52 PM, Andreas Roehler wrote: > Barry Warsaw wrote: >> On Mar 19, 2010, at 05:12 PM, Reinout van Rees wrote: >> >>> On 03/19/2010 04:21 PM, Barry Warsaw wrote: >>>> Any objections to C-c C-e? >>> None at all. That e-for-explain you mentioned sounds fine. >> >> Cool. Bug updated. >> -B >> >> > > Fix is here: > > lp:~a-roehler/python-mode/dont-bind-C-c-C-h-541833 > > Merge? Approved. From jeffrubic at gmail.com Mon Mar 22 06:07:56 2010 From: jeffrubic at gmail.com (Jeff Bauer) Date: Mon, 22 Mar 2010 00:07:56 -0500 Subject: [Python-mode] OT: web-based color theme creator Message-ID: <4BA6FB2C.1070507@rubic.com> If you like to tweak your color themes, check this out: http://alexpogosyan.com/color-theme-creator/ Jeff Bauer Rubicon, Inc. From deniz.a.m.dogan at gmail.com Mon Mar 22 10:01:04 2010 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Mon, 22 Mar 2010 10:01:04 +0100 Subject: [Python-mode] OT: web-based color theme creator In-Reply-To: <4BA6FB2C.1070507@rubic.com> References: <4BA6FB2C.1070507@rubic.com> Message-ID: <7b501d5c1003220201v534acee3qddcddb4612217112@mail.gmail.com> 2010/3/22 Jeff Bauer : > If you like to tweak your color themes, check this out: > > ?http://alexpogosyan.com/color-theme-creator/ > > Jeff Bauer > Rubicon, Inc. > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > Brilliant! -- Deniz Dogan From andreas.roehler at online.de Mon Mar 22 11:17:19 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 22 Mar 2010 11:17:19 +0100 Subject: [Python-mode] Don't bind C-c C-h In-Reply-To: <39DAB885-983B-4001-8DEC-FEFC2048E214@python.org> References: <7b501d5c1003181222m2630ffebw362727dba10e02f4@mail.gmail.com> <4BA29218.30005@online.de> <7b501d5c1003181357w1eebab5cucac8952e4eb1abc9@mail.gmail.com> <4BA31959.4030503@online.de> <7b501d5c1003190257kdd70472w4a505956ec7176e1@mail.gmail.com> <20100319103408.39a53ba6@heresy> <20100319112116.46b6523e@heresy> <20100319123008.3bb082fe@heresy> <4BA686F1.3040703@online.de> <39DAB885-983B-4001-8DEC-FEFC2048E214@python.org> Message-ID: <4BA743AF.9070703@online.de> Barry Warsaw wrote: > On Mar 21, 2010, at 4:52 PM, Andreas Roehler wrote: > >> Barry Warsaw wrote: >>> On Mar 19, 2010, at 05:12 PM, Reinout van Rees wrote: >>> >>>> On 03/19/2010 04:21 PM, Barry Warsaw wrote: >>>>> Any objections to C-c C-e? >>>> None at all. That e-for-explain you mentioned sounds fine. >>> Cool. Bug updated. >>> -B >>> >>> >> Fix is here: >> >> lp:~a-roehler/python-mode/dont-bind-C-c-C-h-541833 >> >> Merge? > > Approved. > > Done From andreas.roehler at online.de Mon Mar 22 12:32:02 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 22 Mar 2010 12:32:02 +0100 Subject: [Python-mode] Towards a PDEE Message-ID: <4BA75532.4000609@online.de> Hi Barry, hello list, as the colors themes matter indicates, idea of an integrated python developing environment meets some wider interest. Which raises the question where to proceed. Integrating more stuff might result into an collection like emacs-w3m. BTW if entered that path, suggest a split of current python-mode.el too, think smaller files grouped thematically as for pdb for example are easier to debug. Not to get folks bewildered, suggest to keep stuff as is in python-mode.el at the known place. But making up a second location, mirroring classic python-mode, augmented by other useful stuff as ipython, maybe color-theme etc. So people may download and install from there a reasonable default ready-to-go, a python emacs augmented mode (PYEAM) as a first step towards of a python development emacs environment (PDEE). (?) Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Mon Mar 22 12:47:48 2010 From: barry at python.org (Barry Warsaw) Date: Mon, 22 Mar 2010 07:47:48 -0400 Subject: [Python-mode] OT: web-based color theme creator In-Reply-To: <7b501d5c1003220201v534acee3qddcddb4612217112@mail.gmail.com> References: <4BA6FB2C.1070507@rubic.com> <7b501d5c1003220201v534acee3qddcddb4612217112@mail.gmail.com> Message-ID: On Mar 22, 2010, at 5:01 AM, Deniz Dogan wrote: > 2010/3/22 Jeff Bauer : >> If you like to tweak your color themes, check this out: >> >> http://alexpogosyan.com/color-theme-creator/ > Brilliant! Indeed! Even though I'm happy with my colors, this is a very cool site. Thanks Shawn . -Barry From barry at python.org Mon Mar 22 13:15:44 2010 From: barry at python.org (Barry Warsaw) Date: Mon, 22 Mar 2010 08:15:44 -0400 Subject: [Python-mode] Towards a PDEE In-Reply-To: <4BA75532.4000609@online.de> References: <4BA75532.4000609@online.de> Message-ID: <20100322081544.392cf2db@heresy> On Mar 22, 2010, at 12:32 PM, Andreas Roehler wrote: >as the colors themes matter indicates, idea of an >integrated python developing environment meets some >wider interest. > >Which raises the question where to proceed. I'm probably not the best person to participate in this. While I definitely can understand the appeal and applaud the effort to provide Python developers with a really fantastic Emacs-based development environment, it's probably not something I would personally use. But hey, I'm old so ignore me and go for it! :) >Integrating more stuff might result into an collection >like emacs-w3m. > >BTW if entered that path, suggest a split of current >python-mode.el too, think smaller files grouped >thematically as for pdb for example are easier to >debug. > >Not to get folks bewildered, suggest to keep stuff as >is in python-mode.el at the known place. But making up >a second location, mirroring classic python-mode, >augmented by other useful stuff as ipython, maybe >color-theme etc. I think you'll have problems keeping two different locations for the same functionality in sync. I'm not in favor of splitting python-mode.el up much personally because I think it's really easy for people to grab and install as one file. Perhaps think about building optional tools around python-mode and keeping python-mode.el as the basic support for .py file editing? I see no reason why this larger effort couldn't be housed inside the python-mode project on Launchpad though, as long as we continue to make it easy (and obvious) how to download and install python-mode.el for those wanting something simpler. -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 Mon Mar 22 14:45:11 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Mon, 22 Mar 2010 14:45:11 +0100 Subject: [Python-mode] Towards a PDEE In-Reply-To: <20100322081544.392cf2db@heresy> References: <4BA75532.4000609@online.de> <20100322081544.392cf2db@heresy> Message-ID: <4BA77467.70104@online.de> Barry Warsaw wrote: > On Mar 22, 2010, at 12:32 PM, Andreas Roehler wrote: > >> as the colors themes matter indicates, idea of an >> integrated python developing environment meets some >> wider interest. >> >> Which raises the question where to proceed. > > I'm probably not the best person to participate in this. While I definitely > can understand the appeal and applaud the effort to provide Python developers > with a really fantastic Emacs-based development environment, it's probably not > something I would personally use. But hey, I'm old so ignore me and go for > it! :) > Maybe exists something which will still raise you up :) >> Integrating more stuff might result into an collection >> like emacs-w3m. >> >> BTW if entered that path, suggest a split of current >> python-mode.el too, think smaller files grouped >> thematically as for pdb for example are easier to >> debug. >> >> Not to get folks bewildered, suggest to keep stuff as >> is in python-mode.el at the known place. But making up >> a second location, mirroring classic python-mode, >> augmented by other useful stuff as ipython, maybe >> color-theme etc. > > I think you'll have problems keeping two different locations for the same > functionality in sync. I'm not in favor of splitting python-mode.el up much > personally because I think it's really easy for people to grab and install as > one file. Perhaps think about building optional tools around python-mode and > keeping python-mode.el as the basic support for .py file editing? > > I see no reason why this larger effort couldn't be housed inside the > python-mode project on Launchpad though, as long as we continue to make it > easy (and obvious) how to download and install python-mode.el for those > wanting something simpler. > > -Barry > > Could realise the augmented mode via branches. Whats needed so far is a separate tar-archive delivering it. A problem not solved that way is the info. `color-theme' for example is quite another item than python. If a branch contains up to hundred el-files then, how to document and/or explain the matter? A step forward maybe would be a closer integration of already existing stuff: presently, if python-mode is on, it knows nothing about doctest-mode... Andreas From rocky.bernstein at gmail.com Sun Mar 21 02:52:51 2010 From: rocky.bernstein at gmail.com (Rocky Bernstein) Date: Sat, 20 Mar 2010 21:52:51 -0400 Subject: [Python-mode] [PDEE] CEDET integration with python-mode.el? In-Reply-To: <20100320223535.GU1205@onerussian.com> References: <87k4tccooo.fsf@pobox.com> <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> <87wrxcar2c.fsf@pobox.com> <20100320022201.GS1205@onerussian.com> <20100320223535.GU1205@onerussian.com> Message-ID: <6cd6de211003201852k490247e9t82de2b37734bdc59@mail.gmail.com> Comments in line. On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko wrote: > > On Sat, 20 Mar 2010, Rohan Nicholls wrote: > > > Ipython + python-mode + python-ropemacs + pylint + flymake + outline > > > >...< > > I have also used such a setup, and it has a lot to offer, but I found > > that it really dies on you when you work with big projects. I think > > >...< > I had similar slowdown/cpu_intensive experience with some versions of > pylint and more or less large projects but then it somehow became sane > again (didn't check if any recent version changelog had any > performance/dependecy_tracking improvements mentioned) > > > emacs frontend to rpdb (command line version of the winpdb debugger), > > which seems to handle threading as well if not better than anyone > > else. Pdb falls down horribly when dealing with multi-threaded > > applications such as a wx-python or zope app. > what about pydb (or even may be a new rewrite pydbgr ?) I bet Rocky > (their author) who is also an emacs user might like to join the forces > to provide adequate glue? Of course, I'm happy to work with folks who are interested in using pydbgr and ensuring it plays nice with other tools. Strategically I'd like to see it and other debuggers of this ilk use DBGp, the remote debugging protocol. See http://xdebug.org/docs-dbgp.php. Right now though pydbgr has remote debugging support using a home-grown protocol based on the Ruby debugger ruby-debug. And by the way, both pydb and pydbgr do support working with threads. As for emacs and debugger integration, see the emacs-dbgr project on github http://github.com/rocky/emacs-dbgr. It has lots of rough edges but personally I use it all the time. Generally though I use it with debuggers such as for Ruby, POSIX shells and gdb since I don't do much Python coding. emacs-dbgr definitely is a much better foundation to work with on the Emacs side for debuggers than gud.el. It makes better use of Emacs Lisp and Emacs built in capabilities. For example it uses marks to store locations in the source and process buffers; it uses a ring to store history locations and buffer-local structs to store debugger information. Right now emacs-dbgr only supports for pydbgr with regards to Python, but adding other debuggers such as pdb, pydb, or rpdb is pretty easy. If someone is interested in that let me know. The gating factor on all of this development work is that the lack of interest in the community. Personally I don't have need to use Python right now, and historically ipython and Python folks haven't been much interested in pydb let alone pydbgr. But to be fair, I'm not sure that historically there has been all that much interest in pdb either. > (CCing him just in case... for the complete > thread see > > http://mail.python.org/pipermail/python-mode/2010-March/000751.html > -- > .-. > =------------------------------ /v\ ----------------------------= > Keep in touch // \\ (yoh@|www.)onerussian.com > Yaroslav Halchenko /( )\ ICQ#: 60653192 > Linux User ^^-^^ [175555] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.roehler at online.de Tue Mar 23 14:04:03 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 23 Mar 2010 14:04:03 +0100 Subject: [Python-mode] [PDEE] CEDET integration with python-mode.el? In-Reply-To: <6cd6de211003201852k490247e9t82de2b37734bdc59@mail.gmail.com> References: <87k4tccooo.fsf@pobox.com> <87sk81cz0m.fsf@pobox.com> <4B9F61DD.4050507@online.de> <4B9F6D69.4020909@siege-engine.com> <87wrxcar2c.fsf@pobox.com> <20100320022201.GS1205@onerussian.com> <20100320223535.GU1205@onerussian.com> <6cd6de211003201852k490247e9t82de2b37734bdc59@mail.gmail.com> Message-ID: <4BA8BC43.1060301@online.de> Rocky Bernstein wrote: > Comments in line. > > On Sat, Mar 20, 2010 at 6:35 PM, Yaroslav Halchenko > > wrote: > > > On Sat, 20 Mar 2010, Rohan Nicholls wrote: > > > Ipython + python-mode + python-ropemacs + pylint + flymake + outline > > > >...< > > I have also used such a setup, and it has a lot to offer, but I found > > that it really dies on you when you work with big projects. I think > > >...< > I had similar slowdown/cpu_intensive experience with some versions of > pylint and more or less large projects but then it somehow became sane > again (didn't check if any recent version changelog had any > performance/dependecy_tracking improvements mentioned) > > > emacs frontend to rpdb (command line version of the winpdb debugger), > > which seems to handle threading as well if not better than anyone > > else. Pdb falls down horribly when dealing with multi-threaded > > applications such as a wx-python or zope app. > what about pydb (or even may be a new rewrite pydbgr ?) > > I bet Rocky > (their author) who is also an emacs user might like to join the forces > to provide adequate glue? > > > Of course, I'm happy to work with folks who are interested in using > pydbgr and ensuring it plays nice with other tools. Strategically I'd > like to see it and other debuggers of this ilk use DBGp, the remote > debugging protocol. See http://xdebug.org/docs-dbgp.php. > > Right now though pydbgr has remote debugging support using a home-grown > protocol based on the Ruby debugger ruby-debug. And by the way, both > pydb and pydbgr do support working with threads. > > As for emacs and debugger integration, see the emacs-dbgr project on github > http://github.com/rocky/emacs-dbgr. It has lots of rough edges but > personally I use it all the time. Generally though I use it with > debuggers such as for Ruby, POSIX shells and gdb since I don't do much > Python coding. > > emacs-dbgr definitely is a much better foundation to work with on the > Emacs side for debuggers than gud.el. It makes better use of Emacs Lisp > and Emacs built in capabilities. For example it uses marks to store > locations in the source and process buffers; it uses a ring to store > history locations and buffer-local structs to store debugger information. > > Right now emacs-dbgr only supports for pydbgr with regards to Python, > but adding other debuggers such as pdb, pydb, or rpdb is pretty easy. If > someone is interested in that let me know. > > The gating factor on all of this development work is that the lack of > interest in the community. Personally I don't have need to use Python > right now, and historically ipython and Python folks haven't been much > interested in pydb let alone pydbgr. But to be fair, I'm not sure that > historically there has been all that much interest in pdb either. Hi Rocky, great to see you here. Not being that experienced python-user either, played a little bit with pydb.el and like it, as it doesn't require an entry into the python-source. Thanks a lot BTW. Most simply way getting your stuff distributed alongside with python-mode seems making a branch and upload it. Once your branch(es) show up, it will be cared for connection into python-mode. If you think that's to much, there should be ways mirrowing your stuff from the place it resides. Thanks again Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ > > > (CCing him just in case... for the complete > thread see > > http://mail.python.org/pipermail/python-mode/2010-March/000751.html > -- > .-. > =------------------------------ /v\ ----------------------------= > Keep in touch // \\ (yoh@|www.)onerussian.com > > Yaroslav Halchenko /( )\ ICQ#: 60653192 > Linux User ^^-^^ [175555] > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From andreas.roehler at online.de Tue Mar 23 22:35:18 2010 From: andreas.roehler at online.de (Andreas Roehler) Date: Tue, 23 Mar 2010 22:35:18 +0100 Subject: [Python-mode] pymacs-start-services fails Message-ID: <4BA93416.6060605@online.de> Hi, get a strange error loading pymacs with GNU Emacs 23.1.92.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2010-02-19 Pymacs-0.24-beta1 pymacs-eval resp. `pymacs-start-services' fails In *Pymacs*-buffer it says: "No module named Pymacs.pymacs" While after python -v in a python-shell from Pymacs.pymacs import main seem to work well: from Pymacs.pymacs import main import Pymacs # directory Pymacs # Pymacs/__init__.pyc matches Pymacs/__init__.py import Pymacs # precompiled from Pymacs/__init__.pyc # Pymacs/pymacs.pyc matches Pymacs/pymacs.py import Pymacs.pymacs # precompiled from Pymacs/pymacs.pyc So modules as such seem present. However, from ipython-shell from Pymacs.pymacs import main fails too with "No module named Pymacs.pymacs" Any ideas? Thanks Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From andreas.roehler at easy-emacs.de Sun Mar 28 09:25:02 2010 From: andreas.roehler at easy-emacs.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 28 Mar 2010 09:25:02 +0200 Subject: [Python-mode] python mode shell and unicode In-Reply-To: <20100328024756.GA4890@bbone> References: <20100326153543.GA11085@bbone> <4BAE44D0.9090804@easy-emacs.de> <20100328024756.GA4890@bbone> Message-ID: <4BAF044E.7010304@easy-emacs.de> Max Arnold wrote: > On Sat, Mar 27, 2010 at 06:48:00PM +0100, Andreas R?hler wrote: >>> My python-shell invoked via C-c C-c from python buffer can not print unicode characters (emits >>> UnicodeEncodeError) and sys.stdout.encoding is empty. System wide LANG set to "ru_RU.UTF-8" and >>> os.environ.get('LANG') in python shell confirms this. >>> >>> When python-shell invoked manually (M-x python-shell) there is no encoding issues. Any ideas? >>> >> What you get from >> C-h v buffer-file-coding-system? > > --- > buffer-file-coding-system is a variable defined in `C source code'. > Its value is utf-8-unix > Local in buffer test1.py; global value is utf-8-unix > ... > It does not apply to sending output to subprocesses, however. > --- > > Python module contains encoding specification # -*- coding: utf-8 -*- at the beginning. > Emacs version is 23.1. > > > Hmm, see inside `python-send-region' ;; Fixme: Write a `coding' header to the temp file if the region is ;; non-ASCII. Maybe that indicates the cause? You could try `py-execute-file' from python-mode.el CC to mailing list there. Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ From andreas.roehler at easy-emacs.de Sun Mar 28 16:56:49 2010 From: andreas.roehler at easy-emacs.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 28 Mar 2010 16:56:49 +0200 Subject: [Python-mode] python mode shell and unicode In-Reply-To: <20100328130822.GA7535@bbone> References: <20100326153543.GA11085@bbone> <4BAE44D0.9090804@easy-emacs.de> <20100328024756.GA4890@bbone> <4BAF044E.7010304@easy-emacs.de> <20100328130822.GA7535@bbone> Message-ID: <4BAF6E31.8020202@easy-emacs.de> Max Arnold wrote: > On Sun, Mar 28, 2010 at 09:25:02AM +0200, Andreas R?hler wrote: >> Hmm, see inside `python-send-region' >> >> ;; Fixme: Write a `coding' header to the temp file if the region is >> ;; non-ASCII. >> >> Maybe that indicates the cause? > > I think this is unrelated to the issue because my python code contains no > unicode characters; they are received from parsed web page and then printed > to stdout. The problem is with python process spawned by Emacs - its stdout > encoding is not specified (sys.stdout.encoding is None). > > Maybe this is a python feature: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415968 > > But then I do not understand why manually invoked pyton-shell handles unicode > characters just fine... Looks like your problem is rather on the python than the emacs side. If I change the function in the bugreport given above into def output(s): # print s.decode('utf-8') print s redirecting into FILE with > works > >> You could try `py-execute-file' from python-mode.el > > Sorry, didn't mentioned that I use python.el shipped with emacs. How to disable > built-in one and enable python-mode.el? Download it here http://launchpad.net/python-mode/trunk/5.1.0/+download/python-mode.el and get it loaded How to invoke py-execute-file from > M-x prompt? Just M-x py-execute-file should do it Andreas > > BTW, print u'\xA9' is a nice test for this issue. > > Cheers, Max > > > From andreas.roehler at easy-emacs.de Sun Mar 28 18:34:06 2010 From: andreas.roehler at easy-emacs.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 28 Mar 2010 18:34:06 +0200 Subject: [Python-mode] python mode shell and unicode In-Reply-To: <20100328163708.GA9749@bbone> References: <20100326153543.GA11085@bbone> <4BAE44D0.9090804@easy-emacs.de> <20100328024756.GA4890@bbone> <4BAF044E.7010304@easy-emacs.de> <20100328130822.GA7535@bbone> <4BAF6E31.8020202@easy-emacs.de> <20100328163708.GA9749@bbone> Message-ID: <4BAF84FE.4040205@easy-emacs.de> Max Arnold wrote: > On Sun, Mar 28, 2010 at 04:56:49PM +0200, Andreas R?hler wrote: >> Looks like your problem is rather on the python than the emacs side. > >> Download it here >> http://launchpad.net/python-mode/trunk/5.1.0/+download/python-mode.el >> >> M-x py-execute-file > > Ok, I placed (require 'python-mode) to init.el and it seems to be activated > (autoloading didn't worked for me). But M-x shows no available completions > for py-execute-file: > > Possible completions are: > py-electric-backspace py-electric-colon > py-electric-delete py-end-of-def-or-class > py-execute-buffer py-execute-def-or-class > py-execute-import-or-reload py-execute-region > py-execute-string > > Although C-h f py-execute-file shows it and says it is defined in python-mode.el. > > > Next, quick test with print u'\xA9': > > 1. Invoke python shell manually: > > M-x py-shell >>>> print u'\xA9' > ? > > > 2. Create new buffer containing the same print command, switch it to python-mode > and use py-execute-buffer: > >>>> ## working on region in file /usr/tmp/python-9773IlV.py... > ? > So that's what it should do(?) > > 3. Close python shell (opened at step 1) and invoke py-execute-buffer again: > > Traceback (most recent call last): > File "", line 1, in > UnicodeEncodeError: 'ascii' codec can't encode character u'\xa9' in position 0: ordinal not in range(128) > > > Is this really a python problem? I think there is a difference in how Emacs spawns python > process in each case. > > > Hmm, yes, get the same error. However, if I re-start ipython-shell parallel it works again In [11]: ## working on region in file /usr/tmp/python-3766xFD.py... ? Maybe just start a python-shell to have a work-around? Sorry, I'm not able to dive into now. It may help, if you make a bug-report, having it noticed at least here: https://bugs.launchpad.net/python-mode Thanks Andreas From andreas.roehler at easy-emacs.de Sun Mar 28 19:28:38 2010 From: andreas.roehler at easy-emacs.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Sun, 28 Mar 2010 19:28:38 +0200 Subject: [Python-mode] python mode shell and unicode In-Reply-To: <20100328175801.GA5783@bbone> References: <20100326153543.GA11085@bbone> <4BAE44D0.9090804@easy-emacs.de> <20100328024756.GA4890@bbone> <4BAF044E.7010304@easy-emacs.de> <20100328130822.GA7535@bbone> <4BAF6E31.8020202@easy-emacs.de> <20100328163708.GA9749@bbone> <4BAF84FE.4040205@easy-emacs.de> <20100328175801.GA5783@bbone> Message-ID: <4BAF91C6.9040205@easy-emacs.de> Max Arnold wrote: > On Sun, Mar 28, 2010 at 06:34:06PM +0200, Andreas R?hler wrote: >>> On Sun, Mar 28, 2010 at 04:56:49PM +0200, Andreas R?hler wrote: >>>> Looks like your problem is rather on the python than the emacs side. >>>> Download it here >>>> http://launchpad.net/python-mode/trunk/5.1.0/+download/python-mode.el >>>> >>>> M-x py-execute-file >>> Ok, I placed (require 'python-mode) to init.el and it seems to be activated >>> (autoloading didn't worked for me). But M-x shows no available completions >>> for py-execute-file: >>> >>> Possible completions are: >>> py-electric-backspace py-electric-colon >>> py-electric-delete py-end-of-def-or-class >>> py-execute-buffer py-execute-def-or-class >>> py-execute-import-or-reload py-execute-region >>> py-execute-string >>> >>> Although C-h f py-execute-file shows it and says it is defined in python-mode.el. >>> >>> >>> Next, quick test with print u'\xA9': >>> >>> 1. Invoke python shell manually: >>> >>> M-x py-shell >>>>>> print u'\xA9' >>> ? >>> >>> >>> 2. Create new buffer containing the same print command, switch it to python-mode >>> and use py-execute-buffer: >>> >>>>>> ## working on region in file /usr/tmp/python-9773IlV.py... >>> ? >>> >> So that's what it should do(?) > > > Yes, (1) and (2) is expected behaviour, 0xA9 is the UTF-8 code for copyright symbol (C). > >>> 3. Close python shell (opened at step 1) and invoke py-execute-buffer again: >>> >>> Traceback (most recent call last): >>> File "", line 1, in >>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa9' in position 0: ordinal not in range(128) >>> >>> >>> Is this really a python problem? I think there is a difference in how Emacs spawns python >>> process in each case. >>> >>> >> Hmm, yes, get the same error. >> However, if I re-start ipython-shell parallel >> >> it works again >> >> In [11]: ## working on region in file /usr/tmp/python-3766xFD.py... >> ? >> >> >> Maybe just start a python-shell to have a work-around? > > Initially I discovered this problem using python.el. It spawns new python > process upon C-c C-c even if there is existing one (looks like it launches > one process per buffer). So this workaround applicable only for python-mode.el > > >> Sorry, I'm not able to dive into now. >> >> It may help, if you make a bug-report, having it noticed at least here: >> >> https://bugs.launchpad.net/python-mode > > Ok, I'll do this. Should I do the same for python.el somewhere? > > > Yes, thanks M-x report-emacs-bug will provide the destination. Andreas