From georg at python.org Thu Feb 3 21:23:40 2011 From: georg at python.org (Georg Brandl) Date: Thu, 03 Feb 2011 21:23:40 +0100 Subject: [Python-mode] python.el Message-ID: <4D4B0ECC.3090700@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From reading emacs-devel, it seems that the python.el has made changes to the mode and explicitly taken them out of the copyright assignment for the FSF, so Emacs upstream can't include them. So now we are at three different python modes for Emacs... :| Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1LDswACgkQN9GcIYhpnLC3OwCeNSUx7IUb76Kuy42uoiCdfWJi cM0Anj3T2/IjCk/QreoVFGcWuGb5huAo =fGwR -----END PGP SIGNATURE----- From barry at python.org Thu Feb 3 22:09:19 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 16:09:19 -0500 Subject: [Python-mode] python.el In-Reply-To: <4D4B0ECC.3090700@python.org> References: <4D4B0ECC.3090700@python.org> Message-ID: <20110203160919.7ac3a0ce@python.org> On Feb 03, 2011, at 09:23 PM, Georg Brandl wrote: >- From reading emacs-devel, it seems that the python.el has made >changes to the mode and explicitly taken them out of the copyright >assignment for the FSF, so Emacs upstream can't include them. > >So now we are at three different python modes for Emacs... :| Wonderful. http://thread.gmane.org/gmane.emacs.devel/135075 We should reach out and see if there's another opportunity for them to adopt python-mode.el. Anybody want to take that on? :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From georg at python.org Thu Feb 3 22:13:44 2011 From: georg at python.org (Georg Brandl) Date: Thu, 03 Feb 2011 22:13:44 +0100 Subject: [Python-mode] python.el In-Reply-To: <20110203160919.7ac3a0ce@python.org> References: <4D4B0ECC.3090700@python.org> <20110203160919.7ac3a0ce@python.org> Message-ID: <4D4B1A88.8030300@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.02.2011 22:09, schrieb Barry Warsaw: > On Feb 03, 2011, at 09:23 PM, Georg Brandl wrote: > >>- From reading emacs-devel, it seems that the python.el has made >>changes to the mode and explicitly taken them out of the copyright >>assignment for the FSF, so Emacs upstream can't include them. >> >>So now we are at three different python modes for Emacs... :| > > Wonderful. > > http://thread.gmane.org/gmane.emacs.devel/135075 > > We should reach out and see if there's another opportunity for them to adopt > python-mode.el. Anybody want to take that on? :) Would we be able to find all the contributors and get them to sign papers for the FSF? Otherwise there's no need to even think about that step. Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1LGocACgkQN9GcIYhpnLBHUACeLy5zcW0pqsK/T9M0n1/PLyp/ prQAnRYLrde07g/TsL+S3jRMUvdJyIUz =XD/Z -----END PGP SIGNATURE----- From skip at pobox.com Thu Feb 3 22:13:59 2011 From: skip at pobox.com (skip at pobox.com) Date: Thu, 3 Feb 2011 15:13:59 -0600 Subject: [Python-mode] python.el In-Reply-To: <4D4B0ECC.3090700@python.org> References: <4D4B0ECC.3090700@python.org> Message-ID: <19787.6807.442865.22766@montanaro.dyndns.org> Georg> - From reading emacs-devel, it seems that the python.el has made Georg> changes to the mode and explicitly taken them out of the Georg> copyright assignment for the FSF, so Emacs upstream can't include Georg> them. Georg> So now we are at three different python modes for Emacs... :| I'm not sure I understand. Someone forked python.el but won't allow the changes to go back into the GNU version? Wouldn't that violate the GPL or LGPL. Who did this? Skip From georg at python.org Thu Feb 3 22:15:49 2011 From: georg at python.org (Georg Brandl) Date: Thu, 03 Feb 2011 22:15:49 +0100 Subject: [Python-mode] python.el In-Reply-To: <19787.6807.442865.22766@montanaro.dyndns.org> References: <4D4B0ECC.3090700@python.org> <19787.6807.442865.22766@montanaro.dyndns.org> Message-ID: <4D4B1B05.8050003@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.02.2011 22:13, schrieb skip at pobox.com: > > Georg> - From reading emacs-devel, it seems that the python.el has made > Georg> changes to the mode and explicitly taken them out of the > Georg> copyright assignment for the FSF, so Emacs upstream can't include > Georg> them. > > Georg> So now we are at three different python modes for Emacs... :| > > I'm not sure I understand. Someone forked python.el but won't allow the > changes to go back into the GNU version? Wouldn't that violate the GPL or > LGPL. Who did this? Sorry, the word "author" is missing in my original message. See the thread linked by Barry, in particular the message by Stefan Monnier, for more details. Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1LGwUACgkQN9GcIYhpnLBfZwCgj4NW4Z9Tw58iQkg861BoEaMX G8wAoJQS+Vm5zrphK3Bj1kw9D/9OuZ9b =WiY2 -----END PGP SIGNATURE----- From skip at pobox.com Thu Feb 3 22:19:44 2011 From: skip at pobox.com (skip at pobox.com) Date: Thu, 3 Feb 2011 15:19:44 -0600 Subject: [Python-mode] python.el In-Reply-To: <20110203160919.7ac3a0ce@python.org> References: <4D4B0ECC.3090700@python.org> <20110203160919.7ac3a0ce@python.org> Message-ID: <19787.7152.853804.475218@montanaro.dyndns.org> Barry> Wonderful. Barry> http://thread.gmane.org/gmane.emacs.devel/135075 Wasn't a lot of our heartburn alwhile ago precipitated by Dave Love? He of the massive-patch-which-must-not-be-divided? In fact, isn't he the original author of the the python.el which *is* delivered with GNU Emacs? He must have a big bee in his bonnet. Skip From dandavison7 at gmail.com Thu Feb 3 20:10:04 2011 From: dandavison7 at gmail.com (Dan Davison) Date: Thu, 03 Feb 2011 19:10:04 +0000 Subject: [Python-mode] Add lambda: as a font-lock keyword Message-ID: Is there any reason not to highlight "lambda:" as a keyword, i.e. when it's immediately followed by a colon? The patch below takes a stab at that. I guess it might be ideal if the colon were not highlighted; I didn't look into that. Thanks very much for the python-mode code and please tell me if there's a more convenient way that I should submit a patch. Dan Highlight lambda as keyword when followed immediately by colon * python-mode.el (python-font-lock-keywords): Add "lambda:" Modified python-mode.el diff --git a/python-mode.el b/python-mode.el index 447c691..79d12d4 100644 --- a/python-mode.el +++ b/python-mode.el @@ -588,7 +588,7 @@ support for features needed by `python-mode'.") ) "\\|")) (kw2 (mapconcat 'identity - '("else:" "except:" "finally:" "try:") + '("else:" "except:" "finally:" "try:" "lambda:") "\\|")) (kw3 (mapconcat 'identity ;; Don't include Ellipsis in this list, since it is From georg at python.org Thu Feb 3 22:26:56 2011 From: georg at python.org (Georg Brandl) Date: Thu, 03 Feb 2011 22:26:56 +0100 Subject: [Python-mode] python.el In-Reply-To: <19787.7152.853804.475218@montanaro.dyndns.org> References: <4D4B0ECC.3090700@python.org> <20110203160919.7ac3a0ce@python.org> <19787.7152.853804.475218@montanaro.dyndns.org> Message-ID: <4D4B1DA0.4060400@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.02.2011 22:19, schrieb skip at pobox.com: > > Barry> Wonderful. > > Barry> http://thread.gmane.org/gmane.emacs.devel/135075 > > Wasn't a lot of our heartburn alwhile ago precipitated by Dave Love? He of > the massive-patch-which-must-not-be-divided? In fact, isn't he the original > author of the the python.el which *is* delivered with GNU Emacs? He must > have a big bee in his bonnet. All true -- well, except for the last one, which I don't really know ;) Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1LHaAACgkQN9GcIYhpnLBH2gCeKSzCOMd08HJUBmWZVfNJVW9T uL4AniwgCOm6f6gC+fG007mayVZbWt4t =H4q0 -----END PGP SIGNATURE----- From georg at python.org Thu Feb 3 22:43:28 2011 From: georg at python.org (Georg Brandl) Date: Thu, 03 Feb 2011 22:43:28 +0100 Subject: [Python-mode] Add lambda: as a font-lock keyword In-Reply-To: References: Message-ID: <4D4B2180.3070601@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right, this has bothered me as well a few times. +1 for the patch. Georg Am 03.02.2011 20:10, schrieb Dan Davison: > Is there any reason not to highlight "lambda:" as a keyword, i.e. when > it's immediately followed by a colon? The patch below takes a stab at > that. I guess it might be ideal if the colon were not highlighted; I > didn't look into that. > > Thanks very much for the python-mode code and please tell me if there's > a more convenient way that I should submit a patch. > > Dan > > > Highlight lambda as keyword when followed immediately by colon > > * python-mode.el (python-font-lock-keywords): Add "lambda:" > > Modified python-mode.el > diff --git a/python-mode.el b/python-mode.el > index 447c691..79d12d4 100644 > --- a/python-mode.el > +++ b/python-mode.el > @@ -588,7 +588,7 @@ support for features needed by `python-mode'.") > ) > "\\|")) > (kw2 (mapconcat 'identity > - '("else:" "except:" "finally:" "try:") > + '("else:" "except:" "finally:" "try:" "lambda:") > "\\|")) > (kw3 (mapconcat 'identity > ;; Don't include Ellipsis in this list, since it is > > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1LIYAACgkQN9GcIYhpnLACzQCgjrIpYB+xelkN4806GDDczjtd 9Y4AnRRzwLSIXP8T3o3QuKVxFJ1MEFjH =SXfI -----END PGP SIGNATURE----- From aculich at gmail.com Thu Feb 3 22:48:10 2011 From: aculich at gmail.com (Aaron Culich) Date: Thu, 3 Feb 2011 13:48:10 -0800 Subject: [Python-mode] python.el In-Reply-To: <19787.6807.442865.22766@montanaro.dyndns.org> References: <4D4B0ECC.3090700@python.org> <19787.6807.442865.22766@montanaro.dyndns.org> Message-ID: On Thu, Feb 3, 2011 at 1:13 PM, wrote: > > Georg> - From reading emacs-devel, it seems that the python.el has made > Georg> changes to the mode and explicitly taken them out of the > Georg> copyright assignment for the FSF, so Emacs upstream can't include > Georg> them. > > Georg> So now we are at three different python modes for Emacs... :| > > I'm not sure I understand. Someone forked python.el but won't allow the > changes to go back into the GNU version? Wouldn't that violate the GPL or > LGPL. Who did this? > > Copyright assignment is an issue separate from the license itself. To the extent that Dave's version is derived from the existing python.el then the GNU GPL still applies to his version of python.el if he distributes it to other people. He is the "owner" of the new code that he has written, so that means if he finds someone that redistributes his code in a manner that is violating the GNU GPL license, then he has the legal standing to pursue that violation in court as the copyright holder. However, no one else has the right to pursue it in court on his behalf; you could bring a case to court, but it would be thrown out in just the same way as if you tried to bring a lawsuit against someone illegally redistributing MS Word; you can't sue someone for that, but Microsoft can if they chose to. The license, whether free or proprietary, can only be enforced in the courts by the copyright holder. The issue of enforcement is one of reasons that the GNU project long ago made a requirement that any code contributions accepted back into the code base and officially branded as GNU software must also have any accompanying copyright assignment. There are other reasons, as well, including protection from patents so that it would prevent someone from contributing source code to the GNU project on one hand, and then on the other hand using patents against the same set of code. You can read that in the language of one of the example copyright assignment forms I've linked to below. -Aaron Here is some further reading: An official statement about why they require copyright assignment: http://www.gnu.org/licenses/why-assign.html An example of the copyright assignment form http://gcc.gnu.org/ml/gcc/2002-09/msg00678.html Excerpt from the above form intended to protect against harm from patents: > The Assigner hereby agrees that if it has or acquires hereafter any > patent or interface copyright or other intellectual property interest > dominating the program enhanced by the Work (or use of that program), such > dominating interest will not be used to undermine the effect of this > assignment, i.e. the Foundation and the general public will be licensed to > use, in that program and its derivative works, without royalty or > limitation, the subject matter of the dominating interest. This license > provision will be binding on the assignees of, or other successors to, the > dominating interest, as well as on the Assigner. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Feb 3 22:53:30 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 16:53:30 -0500 Subject: [Python-mode] python.el In-Reply-To: <4D4B1A88.8030300@python.org> References: <4D4B0ECC.3090700@python.org> <20110203160919.7ac3a0ce@python.org> <4D4B1A88.8030300@python.org> Message-ID: <20110203165330.580540cd@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Feb 03, 2011, at 10:13 PM, Georg Brandl wrote: >Would we be able to find all the contributors and get them to sign papers >for the FSF? Otherwise there's no need to even think about that step. At one point in the distant past we *did* that and sent it to the FSF (IIRC, Tim Peters, Ken M. and myself at the very least). IMHO, they lost the paperwork and we've been lax about tracking it ever since getting rebuffed. But aside from that, I would certainly be willing and able to assign copyright for my changes. Again. I haven't looked at the changelogs in a long time so I don't know how easy it would be to track everyone else down. Tim, Ken, Skip, Andreas, you should all be possible. I don't know if that's enough. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNSyPbAAoJEBJutWOnSwa/AGIP/0YUutvgBUIqmFVuj+w7dTL7 Lyx0w75+z5zsj6PdlEXqmiYxMgaiyoMeLTsunVbBAGh1wWZMHI9/LojPx580eKa5 1UzspXuZ/fPZFCZjuAA0WvHRQtb3hGVLMOF/Hh/NDg8KHJfj4Cx9gfBDATc0YdOT agMYjPvQLXeT+mfzfNRaLITPEBMkJxXa6G38uu7HkbNq0/AD6/RWFjRPUsJaOOE1 XEriv/8RXjBgrjceyJx7BSq6VeKcu1ZGd/PPw1j+obFojZlnN7TUZ2+S7lzwLvbO KTs+Til5SdIItG4ow1QSfFA0rXcACDuYUY3uE/a4U4mBsIA7egOJiuLFEabZX6eL RcvqjO+9lbxjGo+QN3WjkadWcR8sAQXayJCa/ZPg8rP/ZSfy+2ad5F9PQ4fZ8gzG axJINflyNK95ibuFq8QTmHuUj5FmkRMw0XCqmA5KHiKzLnWf/DgugTbQVwf5bClc 6WDLIm2n3f1g6GZHfQgf+s90gp3+Nork7FAa51SzTvBPVucSlK2V9oS9jiyT73m2 U0N1gjohR269gDwG9GfMPg6PSA4ZM0mWZ5tz6lCG3ZmpRV7KirXp5Uc+0x1ngT4W yjpu8eXHmmGxLN9hjwyU/nOuRw2LFNLhxeeolBfOjvonRWhGCuPhaLcu+W986cV4 qfOKbLaheOCzdyFH7KJ9 =+Rvs -----END PGP SIGNATURE----- From skip at pobox.com Thu Feb 3 23:06:22 2011 From: skip at pobox.com (skip at pobox.com) Date: Thu, 3 Feb 2011 16:06:22 -0600 Subject: [Python-mode] python.el In-Reply-To: <20110203165330.580540cd@python.org> References: <4D4B0ECC.3090700@python.org> <20110203160919.7ac3a0ce@python.org> <4D4B1A88.8030300@python.org> <20110203165330.580540cd@python.org> Message-ID: <19787.9950.190544.254188@montanaro.dyndns.org> >> Would we be able to find all the contributors and get them to sign >> papers for the FSF? Otherwise there's no need to even think about >> that step. Barry> At one point in the distant past we *did* that and sent it to the Barry> FSF (IIRC, Tim Peters, Ken M. and myself at the very least). Barry> IMHO, they lost the paperwork and we've been lax about tracking Barry> it ever since getting rebuffed. I'm pretty sure I wet signed the relevant papers in the dim, dark past, though probably not specifically for python-mode. I wouldn't mind repeating myself on that subject. Skip From barry at python.org Fri Feb 4 00:39:49 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 18:39:49 -0500 Subject: [Python-mode] Add lambda: as a font-lock keyword In-Reply-To: References: Message-ID: <20110203183949.1339d50f@python.org> On Feb 03, 2011, at 07:10 PM, Dan Davison wrote: >Is there any reason not to highlight "lambda:" as a keyword, i.e. when >it's immediately followed by a colon? The patch below takes a stab at >that. I guess it might be ideal if the colon were not highlighted; I >didn't look into that. Nope, it's fine for consistency with else: and the others. >Thanks very much for the python-mode code and please tell me if there's >a more convenient way that I should submit a patch. Dan, thanks for your contribution! Patches in emails do tend to get lost in the shuffle. The best way to ensure someone looks at it is to file a bug report here: https://bugs.launchpad.net/python-mode Then you can attach the patch to the bug report, or if you feel comfortable with Bazaar, create a branch, link it to the bug report, and propose a merge with trunk. But a patch attached to a bug, especially for one so small and simple as this, is fine too. :) No worries though, I applied this one in r394. Thanks again! -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 Feb 4 09:16:42 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 04 Feb 2011 09:16:42 +0100 Subject: [Python-mode] python.el In-Reply-To: <4D4B0ECC.3090700@python.org> References: <4D4B0ECC.3090700@python.org> Message-ID: <4D4BB5EA.30503@online.de> Am 03.02.2011 21:23, schrieb Georg Brandl: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - From reading emacs-devel, it seems that the python.el has made > changes to the mode and explicitly taken them out of the copyright > assignment for the FSF, so Emacs upstream can't include them. > > So now we are at three different python modes for Emacs... :| > > Georg Hi Georg, thanks pointing to it. However, let me clarify: Emacs _can_ include, as long it is GPL and it is. And so we can. It's just to give up the insane copyright-policy, where I see no legitime reason for, which denigrates the GPL as such. Andreas From georg at python.org Fri Feb 4 09:48:17 2011 From: georg at python.org (Georg Brandl) Date: Fri, 04 Feb 2011 09:48:17 +0100 Subject: [Python-mode] python.el In-Reply-To: <4D4BB5EA.30503@online.de> References: <4D4B0ECC.3090700@python.org> <4D4BB5EA.30503@online.de> Message-ID: <4D4BBD51.7080908@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.02.2011 09:16, schrieb Andreas R?hler: > Am 03.02.2011 21:23, schrieb Georg Brandl: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> - From reading emacs-devel, it seems that the python.el has made >> changes to the mode and explicitly taken them out of the copyright >> assignment for the FSF, so Emacs upstream can't include them. >> >> So now we are at three different python modes for Emacs... :| >> >> Georg > > Hi Georg, > > thanks pointing to it. > > However, let me clarify: Emacs _can_ include, as long it is GPL and it is. Emacs can include what its maintainers think it can include. And they don't include anything that's not covered by a copyright assignment. I don't think they will change this at any time. > And so we can. Of course we can take stuff out of python.el. > It's just to give up the insane copyright-policy, where I see no > legitime reason for, which denigrates the GPL as such. Which policy are you referring to? If you're referring to Emacs', you'll have to argue this with RMS. Good luck :) Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1LvVEACgkQN9GcIYhpnLDMBACgo/ykWV3K7LSPo2NsWgpYjdn0 0DoAoKS1Ql2iAn03RlBGG5lgBoPSbRkw =85h9 -----END PGP SIGNATURE----- From andreas.roehler at online.de Fri Feb 4 10:03:48 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 04 Feb 2011 10:03:48 +0100 Subject: [Python-mode] python.el In-Reply-To: References: <4D4B0ECC.3090700@python.org> <19787.6807.442865.22766@montanaro.dyndns.org> Message-ID: <4D4BC0F4.9090709@online.de> Am 03.02.2011 22:48, schrieb Aaron Culich: > On Thu, Feb 3, 2011 at 1:13 PM, wrote: > >> >> Georg> - From reading emacs-devel, it seems that the python.el has made >> Georg> changes to the mode and explicitly taken them out of the >> Georg> copyright assignment for the FSF, so Emacs upstream can't include >> Georg> them. >> >> Georg> So now we are at three different python modes for Emacs... :| >> >> I'm not sure I understand. Someone forked python.el but won't allow the >> changes to go back into the GNU version? Wouldn't that violate the GPL or >> LGPL. Who did this? >> >> > Copyright assignment is an issue separate from the license itself. To the > extent that Dave's version is derived from the existing python.el then the > GNU GPL still applies to his version of python.el if he distributes it to > other people. He is the "owner" of the new code that he has written, so that > means if he finds someone that redistributes his code in a manner that is > violating the GNU GPL license, then he has the legal standing to pursue that > violation in court as the copyright holder. However, no one else has the > right to pursue it in court on his behalf; you could bring a case to court, > but it would be thrown out in just the same way as if you tried to bring a > lawsuit against someone illegally redistributing MS Word; you can't sue > someone for that, but Microsoft can if they chose to. The license, whether > free or proprietary, can only be enforced in the courts by the copyright > holder. > > The issue of enforcement is one of reasons that the GNU project long ago > made a requirement that any code contributions accepted back into the code > base and officially branded as GNU software must also have any accompanying > copyright assignment. > > There are other reasons, as well, including protection from patents so that > it would prevent someone from contributing source code to the GNU project on > one hand, and then on the other hand using patents against the same set of > code. You can read that in the language of one of the example copyright > assignment forms I've linked to below. > > -Aaron > > Here is some further reading: > > An official statement about why they require copyright assignment: > http://www.gnu.org/licenses/why-assign.html > > An example of the copyright assignment form > http://gcc.gnu.org/ml/gcc/2002-09/msg00678.html > > Excerpt from the above form intended to protect against harm from patents: > >> The Assigner hereby agrees that if it has or acquires hereafter any >> patent or interface copyright or other intellectual property interest >> dominating the program enhanced by the Work (or use of that program), such >> dominating interest will not be used to undermine the effect of this >> assignment, i.e. the Foundation and the general public will be licensed to >> use, in that program and its derivative works, without royalty or >> limitation, the subject matter of the dominating interest. This license >> provision will be binding on the assignees of, or other successors to, the >> dominating interest, as well as on the Assigner. >> Hi Aaron, saw you digged into this only after sending my short statement with other post. Sorry for that, would have been more explicit seeing the interest in the matter. It is wast one beside. FSF thinks by making these assignment provisions, --partly to the extent of the contributors, setting them on risk rather than the FSF itself-- to do something good. Far from that: by raising the level of specification already it provides uncertainty rather than certainty. Let me point at the risks already introduced by GPL in this globalised world. Any conflict around would endanger contributors, as being summoned before a Bostonian court many of them will not be able to pay the costs. From this perspective GPL already bears a --rather unspecified-- but potential menace and danger for all using it. Decided taking that risk, as you see. But I'm not willing to take more. As for copy-rights I'm protected by our domestic laws, which promess even gratis assistance in certain cases of conflicts. Why should I give up that protection by signing up to US-courts? Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From andreas.roehler at online.de Fri Feb 4 10:27:10 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 04 Feb 2011 10:27:10 +0100 Subject: [Python-mode] python.el In-Reply-To: <4D4B1DA0.4060400@python.org> References: <4D4B0ECC.3090700@python.org> <20110203160919.7ac3a0ce@python.org> <19787.7152.853804.475218@montanaro.dyndns.org> <4D4B1DA0.4060400@python.org> Message-ID: <4D4BC66E.6000901@online.de> [ ... ] He must >> have a big bee in his bonnet. > Always being patient with the genial. Which permits being patient with the common one, including myself. :-) Cheers Andreas From barry at python.org Fri Feb 4 16:30:21 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Feb 2011 10:30:21 -0500 Subject: [Python-mode] python.el In-Reply-To: <4D4BB5EA.30503@online.de> References: <4D4B0ECC.3090700@python.org> <4D4BB5EA.30503@online.de> Message-ID: <20110204103021.6944ca90@python.org> On Feb 04, 2011, at 09:16 AM, Andreas R?hler wrote: >However, let me clarify: Emacs _can_ include, as long it is GPL and it is. But they won't. >And so we can. Yes, we're not bound by the same copyright assignment policy. >It's just to give up the insane copyright-policy, where I see no legitime >reason for, which denigrates the GPL as such. The FSF has their reasons, which I think are legitimate for them. As much as I wish we could merge all the different versions and get python-mode.el into GNU Emacs, it may simply be impossible - or not worth the effort. Apologies for fanning those old flames again. -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 Feb 4 18:37:03 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 04 Feb 2011 18:37:03 +0100 Subject: [Python-mode] python.el In-Reply-To: <20110204103021.6944ca90@python.org> References: <4D4B0ECC.3090700@python.org> <4D4BB5EA.30503@online.de> <20110204103021.6944ca90@python.org> Message-ID: <4D4C393F.9040700@online.de> Am 04.02.2011 16:30, schrieb Barry Warsaw: > On Feb 04, 2011, at 09:16 AM, Andreas R?hler wrote: > >> However, let me clarify: Emacs _can_ include, as long it is GPL and it is. > > But they won't. > >> And so we can. > > Yes, we're not bound by the same copyright assignment policy. > >> It's just to give up the insane copyright-policy, where I see no legitime >> reason for, which denigrates the GPL as such. > > The FSF has their reasons, Hi Barry, I'm consenting to that. There is some rationale. which I think are legitimate for them. > > As much as I wish we could merge all the different versions and get > python-mode.el into GNU Emacs, it may simply be impossible - or not worth the > effort. Policies tend to change. BTW assigned the disclaimer of FSF and there are some lines by me already in GNU Emacs. So assignment is not an absolute barrier even now. :-) Andreas Apologies for fanning those old flames again. > > -Barry From esj at harvee.org Sat Feb 5 02:12:38 2011 From: esj at harvee.org (Eric S. Johansson) Date: Fri, 04 Feb 2011 20:12:38 -0500 Subject: [Python-mode] python.el In-Reply-To: <4D4C393F.9040700@online.de> References: <4D4B0ECC.3090700@python.org> <4D4BB5EA.30503@online.de> <20110204103021.6944ca90@python.org> <4D4C393F.9040700@online.de> Message-ID: <4D4CA406.2070304@harvee.org> On 2/4/2011 12:37 PM, Andreas R?hler wrote: > Am 04.02.2011 16:30, schrieb Barry Warsaw: >> On Feb 04, 2011, at 09:16 AM, Andreas R?hler wrote: >> oh bloody hell, this is the third time I've seen you guys go around this barn. :-) try something different like merging work with the other other python mode or be my coding slave...er, minion... ah, friend with editing privileges to help me make progress on accessibility needs. in all seriousness, please don't waste any more time on the free software foundation. I have decided to not support them anymore since Stallman told me that the needs of free software come before the needs of disabled people. ---eric From skip at pobox.com Sat Feb 5 13:35:46 2011 From: skip at pobox.com (skip at pobox.com) Date: Sat, 5 Feb 2011 06:35:46 -0600 Subject: [Python-mode] python.el In-Reply-To: <4D4CA406.2070304@harvee.org> References: <4D4B0ECC.3090700@python.org> <4D4BB5EA.30503@online.de> <20110204103021.6944ca90@python.org> <4D4C393F.9040700@online.de> <4D4CA406.2070304@harvee.org> Message-ID: <19789.17442.900617.352291@montanaro.dyndns.org> Eric> in all seriousness, please don't waste any more time on the free Eric> software foundation. I have decided to not support them anymore Eric> since Stallman told me that the needs of free software come before Eric> the needs of disabled people. +1. S From andreas.roehler at online.de Sat Feb 5 20:19:24 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Sat, 05 Feb 2011 20:19:24 +0100 Subject: [Python-mode] py-match-paren Message-ID: <4D4DA2BC.2040507@online.de> Hi Barry, herewith a function I'm used to when editing and didn't want miss it in python-mode. Maybe have a look, if it seems useful for others too. Needs (require 'beg-end) (require 'thing-at-point-utils) (require 'thingatpt-utils-base) from https://code.launchpad.net/s-x-emacs-werkstatt/ which are present already in branches: lp:~a-roehler/python-mode/paragraph-fill-warts lp:~a-roehler/python-mode/python-mode-components ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; (define-key py-mode-map [(%)] 'py-match-paren) (defun py-match-paren (arg) "Go to the matching brace, bracket or parenthesis if on its counterpart. Otherwise insert the character, the key is assigned to, here `%'. With universal arg \C-u insert a `%'. " (interactive "P") (if arg (self-insert-command (if (numberp arg) arg 1)) (cond ((looking-at "(") (goto-char (ar-parentized-end-position-atpt)) (backward-char 1)) ((looking-at ")") (goto-char (ar-parentized-beginning-position-atpt))) ((looking-at "\\\[") (goto-char (ar-bracketed-end-position-atpt)) (backward-char 1)) ((looking-at "]") (goto-char (ar-bracketed-beginning-position-atpt))) ((looking-at "{") (goto-char (ar-braced-end-position-atpt)) (backward-char 1)) ((looking-at "}") (goto-char (ar-braced-beginning-position-atpt))) (t (self-insert-command 1)))))) From dandavison7 at gmail.com Thu Feb 10 13:43:47 2011 From: dandavison7 at gmail.com (Dan Davison) Date: Thu, 10 Feb 2011 12:43:47 +0000 Subject: [Python-mode] py-indent-line failure Message-ID: def f(): ''' docstring ''' With point in column zero on the line after the closing triple-quote, py-indent-line fails with Wrong type argument: integerp, t. ,---- | I see there's a cerain amount of TQS stuff in the launchpad bugs already | -- someone let me know if it would be helpful to file this as a new bug, | and I'll do it. `---- I had a quick look but it wasn't clear to me how to fix it. What happens is, here, ;; if we landed inside a string, go to the beginning of that ;; string. this handles triple quoted, multi-line spanning ;; strings. (py-goto-beginning-of-tqs (nth 3 (parse-partial-sexp bod (point)))) parse-partial-sexp returns t as the 4th element, instead of a string delimiter. I see that this is documented behavior for parse-partial-sexp, but I wasn't sure how to alter things to deal with that t. Dan From barry at python.org Thu Feb 10 16:38:53 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 10 Feb 2011 10:38:53 -0500 Subject: [Python-mode] py-indent-line failure In-Reply-To: References: Message-ID: <20110210103853.6e8e3446@python.org> On Feb 10, 2011, at 12:43 PM, Dan Davison wrote: >def f(): > ''' > docstring > ''' > >With point in column zero on the line after the closing triple-quote, >py-indent-line fails with Wrong type argument: integerp, t. wfm: Emacs 23.2.1, python-mode.el r396 -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From dandavison7 at gmail.com Thu Feb 10 17:12:58 2011 From: dandavison7 at gmail.com (Dan Davison) Date: Thu, 10 Feb 2011 16:12:58 +0000 Subject: [Python-mode] py-indent-line failure In-Reply-To: <20110210103853.6e8e3446@python.org> (Barry Warsaw's message of "Thu, 10 Feb 2011 10:38:53 -0500") References: <20110210103853.6e8e3446@python.org> Message-ID: Barry Warsaw writes: > On Feb 10, 2011, at 12:43 PM, Dan Davison wrote: > >>def f(): >> ''' >> docstring >> ''' >> >>With point in column zero on the line after the closing triple-quote, >>py-indent-line fails with Wrong type argument: integerp, t. > > wfm: Emacs 23.2.1, python-mode.el r396 Yes, I confirm that. Broken in emacs 24.0.5.1 but works in 23.2.1. In emacs23, in py-compute-indentation, (parse-partial-sexp bod (point)) returns an integer in 4th position, as opposed to t. My emacs 24 was built from the git repo with HEAD at 41f7693196 (2011/02/02) and my python-mode git repo is at bfaf3a8d05 (2011/02/07) Dan > > -Barry > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode From skip at pobox.com Sun Feb 13 22:50:43 2011 From: skip at pobox.com (skip at pobox.com) Date: Sun, 13 Feb 2011 15:50:43 -0600 Subject: [Python-mode] Latest paragraph-fill-warts branch Message-ID: <19800.21043.600063.701384@montanaro.dyndns.org> I don't know where we left things w.r.t. the Andreas's paragraph-fill-warts branch, but I just updated and fired up a new copy of XEmacs. Then edited my current small test file. After filling the doc string I see the same issue reported before by (I think) Georg. When filling this: """ triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. """ I wind up with this: """ triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. """ That is, the newline after the first tqs and before the last tqs are not preserved. This would have been ideal: """ triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. triple-quoted string containing "quotation" marks. """ Also, take a look at the attached png file. Is it possible to color "quotation" green? Skip -------------- next part -------------- A non-text attachment was scrubbed... Name: warts.png Type: image/png Size: 10318 bytes Desc: not available URL: From andreas.roehler at online.de Mon Feb 14 20:00:35 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Mon, 14 Feb 2011 20:00:35 +0100 Subject: [Python-mode] Latest paragraph-fill-warts branch In-Reply-To: <19800.21043.600063.701384@montanaro.dyndns.org> References: <19800.21043.600063.701384@montanaro.dyndns.org> Message-ID: <4D597BD3.4090006@online.de> Am 13.02.2011 22:50, schrieb skip at pobox.com: > I don't know where we left things w.r.t. the Andreas's paragraph-fill-warts > branch, but I just updated and fired up a new copy of XEmacs. Then edited > my current small test file. After filling the doc string I see the same > issue reported before by (I think) Georg. When filling this: > > """ > triple-quoted string containing "quotation" marks. > triple-quoted string containing "quotation" marks. > triple-quoted string containing "quotation" marks. > triple-quoted string containing "quotation" marks. > triple-quoted string containing "quotation" marks. > """ > > I wind up with this: > > """ triple-quoted string containing "quotation" marks. triple-quoted string > containing "quotation" marks. triple-quoted string containing "quotation" > marks. triple-quoted string containing "quotation" marks. triple-quoted > string containing "quotation" marks. """ > > That is, the newline after the first tqs and before the last tqs are not > preserved. This would have been ideal: > > """ > triple-quoted string containing "quotation" marks. triple-quoted string > containing "quotation" marks. triple-quoted string containing "quotation" > marks. triple-quoted string containing "quotation" marks. triple-quoted > string containing "quotation" marks. > """ > > Also, take a look at the attached png file. Is it possible to color > "quotation" green? > > Skip Hi Skip, the basic reason is XEmacs' syntax bug. Going to do regexp-based string parsing instead. However, detected several bugs in the new parser and just this morning a fundamental one, so I'm re-writing major parts. I'll send a message if ready for testing. As for your last question resp. string colors, this would need a change in fontifying afterwards. As XEmacs already is slow here, I'm not a XEmacs hacker, I'm afraid this will persist - unless someone fixes it. Andreas From georg at python.org Tue Feb 15 14:15:51 2011 From: georg at python.org (Georg Brandl) Date: Tue, 15 Feb 2011 14:15:51 +0100 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel Message-ID: <4D5A7C87.9040700@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't know who else reads emacs-devel, so: http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00655.html https://github.com/fgallina/python.el I haven't looked at the code yet, but it is GPLv3, so if it does stuff better than we do, we could look at it and steal^Wlearn from it... cheers, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1afIcACgkQN9GcIYhpnLCifgCdF6gGFJ6Uwme/KWVnsYSIxq3Z 6zoAnjZwctdXcYfgc2oJtDm/D4q7Cwy/ =jHqW -----END PGP SIGNATURE----- From skip at pobox.com Tue Feb 15 16:51:34 2011 From: skip at pobox.com (skip at pobox.com) Date: Tue, 15 Feb 2011 09:51:34 -0600 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <4D5A7C87.9040700@python.org> References: <4D5A7C87.9040700@python.org> Message-ID: <19802.41222.85384.143579@montanaro.dyndns.org> Georg> I don't know who else reads emacs-devel, so: Georg> http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00655.html Georg> https://github.com/fgallina/python.el Georg> I haven't looked at the code yet, but it is GPLv3, so if it does Georg> stuff better than we do, we could look at it and steal^Wlearn Georg> from it... If he borrowed from python-mode.el I suspect the GNU folks might not accept it since they have so far not been happy with our contribution signatures, right? Skip From georg at python.org Tue Feb 15 16:54:09 2011 From: georg at python.org (Georg Brandl) Date: Tue, 15 Feb 2011 16:54:09 +0100 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <19802.41222.85384.143579@montanaro.dyndns.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> Message-ID: <4D5AA1A1.4070701@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 15.02.2011 16:51, schrieb skip at pobox.com: > Georg> I don't know who else reads emacs-devel, so: > > Georg> http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00655.html > > Georg> https://github.com/fgallina/python.el > > Georg> I haven't looked at the code yet, but it is GPLv3, so if it does > Georg> stuff better than we do, we could look at it and steal^Wlearn > Georg> from it... > > If he borrowed from python-mode.el I suspect the GNU folks might not accept > it since they have so far not been happy with our contribution signatures, > right? IIUC he borrowed from GNU's python.el and wrote all the rest himself. Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1aoaEACgkQN9GcIYhpnLB3LACeKv5CkTACIA5X6UlqppvTt8bY A3kAoJhhgclqQ8cS2SmGHNFnZ/ja3hQY =4I93 -----END PGP SIGNATURE----- From barry at python.org Tue Feb 15 17:23:14 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Feb 2011 11:23:14 -0500 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <4D5AA1A1.4070701@python.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> Message-ID: <20110215112314.149e6c51@python.org> On Feb 15, 2011, at 04:54 PM, Georg Brandl wrote: >IIUC he borrowed from GNU's python.el and wrote all the rest himself. Yep, that's what his announcement said. I agree that I see no reason why python-mode.el can't borrow liberally from 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 skip at pobox.com Tue Feb 15 18:51:22 2011 From: skip at pobox.com (skip at pobox.com) Date: Tue, 15 Feb 2011 11:51:22 -0600 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <20110215112314.149e6c51@python.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> Message-ID: <19802.48410.6382.252689@montanaro.dyndns.org> >> IIUC he borrowed from GNU's python.el and wrote all the rest himself. Barry> Yep, that's what his announcement said. Barry> I agree that I see no reason why python-mode.el can't borrow Barry> liberally from it. :) OTOH, if it works with XEmacs, why not just declare victory and go home? S From andreas.roehler at online.de Tue Feb 15 19:57:34 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 15 Feb 2011 19:57:34 +0100 Subject: [Python-mode] paragraph-fill-warts Message-ID: <4D5ACC9E.6080205@online.de> Hi Skip, paragraph-fill-warts bug should be cured now for XEmacs too in python-mode-components branch. Will set branch `paragraph-fill-warts' on `obsolet'. Realised finally the related XEmacs-compat stuff inside python-mode-components, which turned out much easier. Might be some differences in the API. `py-fill-paragraph' should work, but M-q `fill-paragraph' not - due to a bug in fill.el. Will see how the new python.el deals with that :) Exists a test `py-fill-paragraph-problems-710373' in py-bug-numbered-tests.el which worked for me with XEmacs 21.5 Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Tue Feb 15 20:27:39 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Feb 2011 14:27:39 -0500 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <19802.48410.6382.252689@montanaro.dyndns.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> Message-ID: <20110215142739.06aee6aa@python.org> On Feb 15, 2011, at 11:51 AM, skip at pobox.com wrote: > > >> IIUC he borrowed from GNU's python.el and wrote all the rest himself. > > Barry> Yep, that's what his announcement said. > > Barry> I agree that I see no reason why python-mode.el can't borrow > Barry> liberally from it. :) > >OTOH, if it works with XEmacs, why not just declare victory and go home? Have you tried it? I'd be pretty surprised if it worked better, since the Emacs developers haven't been very proactive about supporting XEmacs. -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 Feb 15 20:52:25 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Tue, 15 Feb 2011 20:52:25 +0100 Subject: [Python-mode] release? Message-ID: <4D5AD979.3090606@online.de> Hi Barry, from my perspective a release is feasible, after triple quoted string bugs should be gone. After release, I'll toggle the bug flags, so it will no longer list as open. Also would do a release of python-components-mode afterwards, which should fix the paragraph-fill bugs too. Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From barry at python.org Tue Feb 15 20:54:00 2011 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Feb 2011 14:54:00 -0500 Subject: [Python-mode] release? In-Reply-To: <4D5AD979.3090606@online.de> References: <4D5AD979.3090606@online.de> Message-ID: <20110215145400.5d11aa28@python.org> On Feb 15, 2011, at 08:52 PM, Andreas R?hler wrote: >from my perspective a release is feasible, after triple >quoted string bugs should be gone. Sorry, I don't quite understand. Do you mean that we should release r396 or that you have a few more patches to go in to fix the triple quoted string bugs? Is the NEWS file up to date? Also, would this be a 5.3.0 or 5.2.1? >After release, I'll toggle the bug flags, so it will no >longer list as open. > >Also would do a release of python-components-mode afterwards, >which should fix the paragraph-fill bugs too. Let me know when you're ready and I push the release button. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From eric.holbrook.3rd at gmail.com Wed Feb 16 01:05:19 2011 From: eric.holbrook.3rd at gmail.com (Eric Holbrook) Date: Tue, 15 Feb 2011 18:05:19 -0600 Subject: [Python-mode] interpreter selection with CarbonEmacs on OSX Message-ID: <4D5B14BF.5070204@gmail.com> What's the best way to tell python-mode to use, say, /opt/local/bin/python, instead of what OS X thinks is the right version? The problem is that when i launch /Applications/Emacs.app from Quicksilver it knows nothing about what i have set up in my .bashrc, so it picks the first (only) python that it finds from the system global environment.plist. Is there a safe way to tell emacs about all the $PATH stuff i have in my .bashrc w/o editing the env vars in my ~/.MacOS/environment.plist? thanks in advance, Eric From skip at pobox.com Wed Feb 16 18:06:18 2011 From: skip at pobox.com (skip at pobox.com) Date: Wed, 16 Feb 2011 11:06:18 -0600 Subject: [Python-mode] paragraph-fill-warts In-Reply-To: <4D5ACC9E.6080205@online.de> References: <4D5ACC9E.6080205@online.de> Message-ID: <19804.1034.48369.401073@montanaro.dyndns.org> Andreas> paragraph-fill-warts bug should be cured now for XEmacs too in Andreas> python-mode-components branch. Andreas> Will set branch `paragraph-fill-warts' on `obsolet'. So I need to abandon my current checkout and replace it with this other branch? Is there some way to (easily) just update my paragraph-fill-warts branch to the python-mode-components branch? I feel like I'm starting to play whack-a-mole. Skip From skip at pobox.com Wed Feb 16 18:11:00 2011 From: skip at pobox.com (skip at pobox.com) Date: Wed, 16 Feb 2011 11:11:00 -0600 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <20110215142739.06aee6aa@python.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> Message-ID: <19804.1316.868762.345536@montanaro.dyndns.org> Barry> I agree that I see no reason why python-mode.el can't borrow Barry> liberally from it. :) >> >> OTOH, if it works with XEmacs, why not just declare victory and go >> home? Barry> Have you tried it? I'd be pretty surprised if it worked better, Barry> since the Emacs developers haven't been very proactive about Barry> supporting XEmacs. I haven't tried it though I suspect you're right. However, how in the hell else are we ever going to reduce the number of different Python modes? So, today the new python.el maintainer seems happy. Assume GNU Emacs sucks it up. Two years from now the maintainer gets cranky, has a kid, I don't know, but something causes him to stop maintaining the code. You wind up with something which causes yet another fork. Will the GNU Emacs people ever accept XEmacs compatibility fixes? It's ridiculous. I don't want to be a developer of this stuff. I just want it to work. Maybe it's just time to face the music and conclude that I should switch away from XEmacs. *sigh* S From barry at python.org Wed Feb 16 18:34:18 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 16 Feb 2011 12:34:18 -0500 Subject: [Python-mode] paragraph-fill-warts In-Reply-To: <19804.1034.48369.401073@montanaro.dyndns.org> References: <4D5ACC9E.6080205@online.de> <19804.1034.48369.401073@montanaro.dyndns.org> Message-ID: <20110216123418.00d0fbc4@python.org> On Feb 16, 2011, at 11:06 AM, skip at pobox.com wrote: > Andreas> paragraph-fill-warts bug should be cured now for XEmacs too in > Andreas> python-mode-components branch. > > Andreas> Will set branch `paragraph-fill-warts' on `obsolet'. > >So I need to abandon my current checkout and replace it with this other >branch? Is there some way to (easily) just update my paragraph-fill-warts >branch to the python-mode-components branch? Skip, even if Andreas obsoletes his branch, yours will not stop working. It just sets a status on Launchpad and of course Andreas won't be updating it any more, so it will get out of date. Really the easiest thing for you to do is to check out the new branch into a different directory and point your load-path at it. Or wait for Andreas to merge the new branch into the trunk and just switch to that. I know it kind of sucks, but it's not that much different than any other vcs. -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 Feb 16 18:34:36 2011 From: sesquile at gmail.com (m h) Date: Wed, 16 Feb 2011 10:34:36 -0700 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <19804.1316.868762.345536@montanaro.dyndns.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> <19804.1316.868762.345536@montanaro.dyndns.org> Message-ID: On Wed, Feb 16, 2011 at 10:11 AM, wrote: > ? ?Barry> I agree that I see no reason why python-mode.el can't borrow > ? ?Barry> liberally from it. :) > ? ?>> > ? ?>> OTOH, if it works with XEmacs, why not just declare victory and go > ? ?>> home? > > ? ?Barry> Have you tried it? ?I'd be pretty surprised if it worked better, > ? ?Barry> since the Emacs developers haven't been very proactive about > ? ?Barry> supporting XEmacs. > > I haven't tried it though I suspect you're right. ?However, how in the hell > else are we ever going to reduce the number of different Python modes? ?So, > today the new python.el maintainer seems happy. ?Assume GNU Emacs sucks it > up. ?Two years from now the maintainer gets cranky, has a kid, I don't know, > but something causes him to stop maintaining the code. ?You wind up with > something which causes yet another fork. ?Will the GNU Emacs people ever > accept XEmacs compatibility fixes? >From current conversations on the emacs ml it looks likely that this new mode could replace current python.el. The idea is to replace the current mode's functionality bit by bit. Though I haven't tried the new mode, it claims pdbtrack support (which is probably the most compelling feature of python-mode.el to me). Moving forward, some options would be: * patch the new mode so it works with xemacs * patch the new code to pull in any missing python-mode.el functionality The latter could be seen as a merge that would give a one true mode with superset functionality. It would also get python-mode effectively into the emacs distribution (ending the recurring "when will copyright assignment be given to the FSF threads seen every so often". > > It's ridiculous. ?I don't want to be a developer of this stuff. ?I just want > it to work. ?Maybe it's just time to face the music and conclude that I > should switch away from XEmacs. ?*sigh* I think most Python users agree with you (that we just want stuff to work). But to be honest emacs kind of requires some tweaking to your needs ;) WRT switching from XEmacs, what is your reason for using it? Curious minds want to know. :) cheers, -matt From skip at pobox.com Wed Feb 16 18:42:24 2011 From: skip at pobox.com (skip at pobox.com) Date: Wed, 16 Feb 2011 11:42:24 -0600 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> <19804.1316.868762.345536@montanaro.dyndns.org> Message-ID: <19804.3200.418218.410329@montanaro.dyndns.org> mh> WRT switching from XEmacs, what is your reason for using it? mh> Curious minds want to know. :) History. Moving is hard. Skip From barry at python.org Wed Feb 16 18:48:34 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 16 Feb 2011 12:48:34 -0500 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <19804.1316.868762.345536@montanaro.dyndns.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> <19804.1316.868762.345536@montanaro.dyndns.org> Message-ID: <20110216124834.15212c54@python.org> On Feb 16, 2011, at 11:11 AM, skip at pobox.com wrote: >I haven't tried it though I suspect you're right. However, how in the hell >else are we ever going to reduce the number of different Python modes? So, >today the new python.el maintainer seems happy. Assume GNU Emacs sucks it >up. Two years from now the maintainer gets cranky, has a kid, I don't know, >but something causes him to stop maintaining the code. You wind up with >something which causes yet another fork. Will the GNU Emacs people ever >accept XEmacs compatibility fixes? Honestly, I doubt it, but if the new python.el maintainer were reasonable, he'd accept patches for XEmacs compatibility. The harsh reality is that he probably won't be very motivated to develop those patches. But really, none of this would have happened if the Emacs people had resolved whatever problems they had with python-mode.el and just used it. Whatever. I'm not going down that path again. ;) >It's ridiculous. I don't want to be a developer of this stuff. I just want >it to work. Maybe it's just time to face the music and conclude that I >should switch away from XEmacs. *sigh* I faced the very same dilemma two years ago. You know me, I was a XEmacs user since it was called Lucid Emacs. I loved it and I had tons of very cool specializations and custom elisp to make it work exactly how I wanted it to. Every few years I'd give GNU Emacs another try, find that it was missing some crucial stuff I really needed, and abandoned the effort. Then two years ago I was at a team sprint and I realized that not only was I in the minority as an *macs user (yes, all the kids seem to flock to Vim these days), but I was *really* an outcast as a XEmacs user. So I gave GNU Emacs one more chance and found that not only was almost everything I cared about in there, but I was also able to remove significant amounts of my custom elisp, and had my environment ported in just a couple of days. I honestly don't even miss XEmacs any more. I had a moment of silence for a great editor and moved on. It's sad to say, because Lucid Emacs/XEmacs was a great and very innovative editor in its day. Heck, I was almost even hired by Lucid to take over maintainership of it from JWZ[*]. But I think XEmacs's days are numbered if it isn't already irrelevant. GNU Emacs has re-established its leadership in innovation and has won back any lost mindshare. I apologized to Stephen Turnbull for my defection, but even he couldn't blame me too much. ;) I can only say that it wasn't that difficult to migrate, so you may want to give it a shot. If you were going to be at Pycon, I'd even give you a hand. -Barry [*] Moving to California, and Lucid's bankruptcy a few weeks after my interview kind of put the kibosh on *that* career move, which as it turns out was a good thing, or I'd never had met and worked with Guido. -------------- 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 Wed Feb 16 18:51:37 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 16 Feb 2011 12:51:37 -0500 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> <19804.1316.868762.345536@montanaro.dyndns.org> Message-ID: <20110216125137.57a1bd55@python.org> On Feb 16, 2011, at 10:34 AM, m h wrote: >* patch the new code to pull in any missing python-mode.el functionality > >The latter could be seen as a merge that would give a one true mode >with superset functionality. It would also get python-mode >effectively into the emacs distribution (ending the recurring "when >will copyright assignment be given to the FSF threads seen every so >often". That might be the most fruitful avenue for a merge. I don't have the cycles to do that, but perhaps Andreas could reach out to the new python.el author on our behalf and see about the feasibility of that. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From esj at harvee.org Wed Feb 16 19:17:31 2011 From: esj at harvee.org (Eric S. Johansson) Date: Wed, 16 Feb 2011 13:17:31 -0500 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> <19804.1316.868762.345536@montanaro.dyndns.org> Message-ID: <4D5C14BB.1050403@harvee.org> On 2/16/2011 12:34 PM, m h wrote: > WRT switching from XEmacs, what is your reason for using it? Curious > minds want to know. :) My reason is simple. I consider Stallman delusional. 1) he considers the needs of free software to be dominant over the needs of disabled users. 2) he appears to believe that NaturallySpeaking quality speech recognition can be developed in less than a couple of years. 2a) he doesn't recognize that people are hurting now. Tens of thousands of developers are injured every year and leave the field because there's no support for disabled developer. 3) he appears to believe that a complete speech corpus can be developed without any control over microphones, soundcards, data rates. 4) he cannot conceive of any way in which you can build a hybrid open/closed source system with a clearly defined boundary so that disabled users can make use of essential accessibility software to drive open source software. 5) he believes that integrating Emacs with nonfree accessibility software enhances the value of accessibility software. My perspective is that it enhances the value of Emacs because Emacs and other free software is now accessible to a larger audience. Personally, for me Emacs or Xemacs are two different ways to lose. With Emacs, I lose by getting zero support or, what seems at times to be negative support. with Xemacs, I lose by what appears to be in overwhelm project with an inadequate number of supporters. They were much more supportive of my accessibility issues but, seeing with Skip is going through is making me a bit nervous. All I want is to make progress so I can try out new usability models for writing software using speech recognition. I don't want to learn Emacs Lisp I don't sync my life into Windows edit controls but I know I'm probably going to have to. But I really want to just focus on the user interface models and save my hands for other things. To tell you the truth, I'm not even sure Python-modal do I want. I need very fine grained feature oriented navigation and selection. I need to identify instances and arguments and other components that may occur and a lot of code. ---eric From andrea.crotti.0 at gmail.com Thu Feb 17 09:11:17 2011 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Thu, 17 Feb 2011 09:11:17 +0100 Subject: [Python-mode] interpreter selection with CarbonEmacs on OSX In-Reply-To: <4D5B14BF.5070204@gmail.com> References: <4D5B14BF.5070204@gmail.com> Message-ID: Il giorno 16/feb/2011, alle ore 01.05, Eric Holbrook ha scritto: > What's the best way to tell python-mode to use, say, /opt/local/bin/python, instead of what OS X thinks is the right version? > > The problem is that when i launch /Applications/Emacs.app from Quicksilver it knows nothing about what i have set up in my .bashrc, so it picks the first (only) python that it finds from the system global environment.plist. Is there a safe way to tell emacs about all the $PATH stuff i have in my .bashrc w/o editing the env vars in my ~/.MacOS/environment.plist? > > thanks in advance, > Eric Since I'm lazy I just launch emacs from a shell, so I'm sure that I get all the variables set correctly. I frankly have no intention to modify a stupid plist file just to get some environment variables set... From andreas.roehler at online.de Thu Feb 17 16:26:42 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Thu, 17 Feb 2011 16:26:42 +0100 Subject: [Python-mode] Announcement of a new python major-mode on emacs-devel In-Reply-To: <20110216125137.57a1bd55@python.org> References: <4D5A7C87.9040700@python.org> <19802.41222.85384.143579@montanaro.dyndns.org> <4D5AA1A1.4070701@python.org> <20110215112314.149e6c51@python.org> <19802.48410.6382.252689@montanaro.dyndns.org> <20110215142739.06aee6aa@python.org> <19804.1316.868762.345536@montanaro.dyndns.org> <20110216125137.57a1bd55@python.org> Message-ID: <4D5D3E32.60100@online.de> Am 16.02.2011 18:51, schrieb Barry Warsaw: > On Feb 16, 2011, at 10:34 AM, m h wrote: > >> * patch the new code to pull in any missing python-mode.el functionality >> >> The latter could be seen as a merge that would give a one true mode >> with superset functionality. It would also get python-mode >> effectively into the emacs distribution (ending the recurring "when >> will copyright assignment be given to the FSF threads seen every so >> often". > > That might be the most fruitful avenue for a merge. I don't have the cycles > to do that, but perhaps Andreas could reach out to the new python.el author on > our behalf and see about the feasibility of that. > > -Barry > > Hi Barry, AFAIS all the python modes own a lot from each other, so there are not really different modes but branches. The new python.el comes with some interesting docu features, we should check and maybe pick. For the moment I'm still at the syntax- resp. XEmacs-compat ie non-syntax-parsing issue. The latter is slower but somehow interesting, as purely emacs-lisp based and looks promising for some more tasks beside python-string-detection. However, not ready yet... Andreas From andreas.roehler at online.de Thu Feb 17 16:39:10 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Thu, 17 Feb 2011 16:39:10 +0100 Subject: [Python-mode] release? In-Reply-To: <20110215145400.5d11aa28@python.org> References: <4D5AD979.3090606@online.de> <20110215145400.5d11aa28@python.org> Message-ID: <4D5D411E.7080800@online.de> Am 15.02.2011 20:54, schrieb Barry Warsaw: > On Feb 15, 2011, at 08:52 PM, Andreas R?hler wrote: > >>from my perspective a release is feasible, after triple >> quoted string bugs should be gone. > > Sorry, I don't quite understand. Do you mean that we should release r396 or > that you have a few more patches to go in to fix the triple quoted string > bugs? > Hmm, the bugs exists only for XEmacs now AFAIS. But fixing it there will open more bugs then closing that way probably. Which doesn't mean it's a bad thing, because it should open some route to much more gains. However, it's not a simple bug-fix. Therefor would close the tqs-reports setting it to "released". Not sure, if previous release already took the syntax patch. If yes, could toggle the reports now. Andreas > Is the NEWS file up to date? > > Also, would this be a 5.3.0 or 5.2.1? > >> After release, I'll toggle the bug flags, so it will no >> longer list as open. >> >> Also would do a release of python-components-mode afterwards, >> which should fix the paragraph-fill bugs too. > > Let me know when you're ready and I push the release button. > -Barry From barry at python.org Thu Feb 17 22:44:31 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 17 Feb 2011 16:44:31 -0500 Subject: [Python-mode] release? In-Reply-To: <4D5D411E.7080800@online.de> References: <4D5AD979.3090606@online.de> <20110215145400.5d11aa28@python.org> <4D5D411E.7080800@online.de> Message-ID: <20110217164431.280e81fb@python.org> On Feb 17, 2011, at 04:39 PM, Andreas R?hler wrote: >Hmm, the bugs exists only for XEmacs now AFAIS. > >But fixing it there will open more bugs then closing that way probably. >Which doesn't mean it's a bad thing, because it should open some route to much more gains. However, it's not a simple bug-fix. > >Therefor would close the tqs-reports setting it to "released". >Not sure, if previous release already took the syntax patch. > >If yes, could toggle the reports now. Andreas, I actually realize that you are a member of ~python-mode-devs so you should be able to do a release on your own. Why don't you give it a try and let me/us know if you have any problems. You could even send the announcement to python-announce at python.org. You're doing most of the work these days, so you should get the credit. :) -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 Feb 18 19:14:33 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Fri, 18 Feb 2011 19:14:33 +0100 Subject: [Python-mode] release? In-Reply-To: <20110217164431.280e81fb@python.org> References: <4D5AD979.3090606@online.de> <20110215145400.5d11aa28@python.org> <4D5D411E.7080800@online.de> <20110217164431.280e81fb@python.org> Message-ID: <4D5EB709.5020708@online.de> Am 17.02.2011 22:44, schrieb Barry Warsaw: > On Feb 17, 2011, at 04:39 PM, Andreas R?hler wrote: > >> Hmm, the bugs exists only for XEmacs now AFAIS. >> >> But fixing it there will open more bugs then closing that way probably. >> Which doesn't mean it's a bad thing, because it should open some route to much more gains. However, it's not a simple bug-fix. >> >> Therefor would close the tqs-reports setting it to "released". >> Not sure, if previous release already took the syntax patch. >> >> If yes, could toggle the reports now. > > Andreas, > > I actually realize that you are a member of ~python-mode-devs so you should be > able to do a release on your own. Why don't you give it a try and let me/us > know if you have any problems. You could even send the announcement to > python-announce at python.org. > > You're doing most of the work these days, so you should get the credit. :) > > -Barry Thanks a lot, Barry, as for the tqs I remember you just answered these days it works for you. I'll close these reports then. Remain several other indent-bugs - beside stuff not touched yet. Hopefully next week we can have a bugfix release of the trunk. Andreas From dandavison7 at gmail.com Tue Feb 22 04:27:18 2011 From: dandavison7 at gmail.com (Dan Davison) Date: Mon, 21 Feb 2011 19:27:18 -0800 Subject: [Python-mode] interpreter selection with CarbonEmacs on OSX In-Reply-To: <4D5B14BF.5070204@gmail.com> (Eric Holbrook's message of "Tue, 15 Feb 2011 18:05:19 -0600") References: <4D5B14BF.5070204@gmail.com> Message-ID: Eric Holbrook writes: > What's the best way to tell python-mode to use, say, > /opt/local/bin/python, instead of what OS X thinks is the right > version? > > The problem is that when i launch /Applications/Emacs.app from > Quicksilver it knows nothing about what i have set up in my .bashrc, > so it picks the first (only) python that it finds from the system > global environment.plist. Is there a safe way to tell emacs about all > the $PATH stuff i have in my .bashrc w/o editing the env vars in my > ~/.MacOS/environment.plist? Hi Eric, Fwiw I have the code below in my .emacs to make sure that emacs picks up the executables I want it to pick up. Basically the game is that you want both (getenv "PATH") and the emacs variable `exec-path' to have the correct paths. You'd need to modify this to suit your needs, but it should be straightforward (reply here if not). Dan #+begin_src emacs-lisp (defvar ded/operating-system (intern (downcase (replace-regexp-in-string "\n" "" (shell-command-to-string "uname")))) "The current OS") (require 'cl) (defun ded/set-executable-paths () "Set $PATH and `exec-path'." (interactive) (let* (($HOME (getenv "HOME")) ($HOME/bin (concat $HOME "/" "bin")) ($PATH (delete-dups (split-string (getenv "PATH") path-separator))) (paths (case ded/operating-system ('darwin (list $HOME/bin "/usr/local/Cellar/python2.6/2.6.5/bin/" "/usr/local/bin" "/usr/texbin")) (t (list $HOME/bin))))) (setenv "PATH" (mapconcat 'identity (append (remove-if (lambda (p) (member p $PATH)) paths) $PATH) path-separator)) (setq exec-path (append (remove-if (lambda (p) (member p exec-path)) paths) (delete-dups exec-path))))) (ded/set-executable-paths) #+end_src > > thanks in advance, > Eric From andrea.crotti.0 at gmail.com Fri Feb 25 12:18:26 2011 From: andrea.crotti.0 at gmail.com (andrea crotti) Date: Fri, 25 Feb 2011 12:18:26 +0100 Subject: [Python-mode] highlight bug? Message-ID: Before I wasn't sure if it was an old bug, but today I got the last revision from bzr and I see the same. Function and variable names containing reserved keywords are not highlighted correctly. For example in def generate_random_tuple() tuple is colored as it was the tuple function call... Anyone else seeing this? By the way I've seen many comments about it but I never really understood, why this python-mode is not included in emacs instead of the crappy default one? From andreas.roehler at online.de Fri Feb 25 13:20:30 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Feb 2011 13:20:30 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: References: Message-ID: <4D679E8E.7060403@online.de> Am 25.02.2011 12:18, schrieb andrea crotti: > Before I wasn't sure if it was an old bug, but today I got the last > revision from bzr and I see the same. > > Function and variable names containing reserved keywords are not > highlighted correctly. > For example in > > def generate_random_tuple() > > tuple is colored as it was the tuple function call... > Anyone else seeing this? Hi Andrea, thanks for the report. Could you make an entry in the bug-tracker at launchpad? That would help. Did you check out the trunk? Highlight bugs have been fixed last weeks. BTW can't reproduce it with my personal components branch. As I'm still behind indent issues, would look further at a later time. > By the way I've seen many comments about it but I never really > understood, why this python-mode is not included > in emacs instead of the crappy default one? Hmm, it's a little bit more complicated IMHO. At python.el was done the the triple-quoted-string syntax fix lately, where we profit from. Also python.el merged in a lot from python-mode.el last month's. So the code base looks not so different now. Let's see if we can assist each other to have a nice python environment Thanks again Andreas > _______________________________________________ > Python-mode mailing list > Python-mode at python.org > http://mail.python.org/mailman/listinfo/python-mode > From andrea.crotti.0 at gmail.com Fri Feb 25 13:32:06 2011 From: andrea.crotti.0 at gmail.com (andrea crotti) Date: Fri, 25 Feb 2011 13:32:06 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: <4D679E8E.7060403@online.de> References: <4D679E8E.7060403@online.de> Message-ID: Ok first I need to be sure I'm up to date. I'm at revision 396, and also here https://code.launchpad.net/~python-mode-devs/+ownedbranches I see the same as last commit done... Are there any more advanced branches? For python-mode/python.el good to know, as long as it's sharing and helping and not fighting is not a problem... From barry at python.org Fri Feb 25 15:56:03 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Feb 2011 09:56:03 -0500 Subject: [Python-mode] highlight bug? In-Reply-To: References: Message-ID: <20110225095603.752cea53@limelight.wooz.org> On Feb 25, 2011, at 12:18 PM, andrea crotti wrote: >Before I wasn't sure if it was an old bug, but today I got the last >revision from bzr and I see the same. > >Function and variable names containing reserved keywords are not >highlighted correctly. >For example in > >def generate_random_tuple() > >tuple is colored as it was the tuple function call... >Anyone else seeing this? Not me. With r396 of python-mode.el I see this highlighting correctly. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From andrea.crotti.0 at gmail.com Fri Feb 25 16:30:08 2011 From: andrea.crotti.0 at gmail.com (andrea crotti) Date: Fri, 25 Feb 2011 16:30:08 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: <4D67CAF2.3020405@online.de> References: <4D679E8E.7060403@online.de> <4D67CAF2.3020405@online.de> Message-ID: 2011/2/25 Andreas R?hler : > usually I start here: > > https://code.launchpad.net/python-mode > BTW my components branch is still heavily changed, major changes underway... > > Have a look at the thing-at-point utils stuff nonetheless, for me it's a > rocket....~~~:===> > >> For python-mode/python.el good to know, as long as it's sharing and >> helping and not fighting is not a problem... >> Oh God I found the problem, I think probably after the last update of cedet I have this not so funny behaviour When emacs starts I get this: python-mode is an interactive compiled Lisp function in `python-mode.el'. After I open the first python file it becomes: "python-mode is an interactive compiled Lisp function in `python.el'. (python-mode)" So I'm just using the wrong thing but I didn't notice because "locate-library" also gave me the right file. Any way to solve this "conflict" once for all? From andreas.roehler at online.de Fri Feb 25 16:29:54 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Feb 2011 16:29:54 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: References: <4D679E8E.7060403@online.de> Message-ID: <4D67CAF2.3020405@online.de> Am 25.02.2011 13:32, schrieb andrea crotti: > Ok first I need to be sure I'm up to date. > I'm at revision 396, and also here > https://code.launchpad.net/~python-mode-devs/+ownedbranches > I see the same as last commit done... > > Are there any more advanced branches? > usually I start here: https://code.launchpad.net/python-mode BTW my components branch is still heavily changed, major changes underway... Have a look at the thing-at-point utils stuff nonetheless, for me it's a rocket....~~~:===> > For python-mode/python.el good to know, as long as it's sharing and > helping and not fighting is not a problem... > From andrea.crotti.0 at gmail.com Fri Feb 25 16:35:39 2011 From: andrea.crotti.0 at gmail.com (andrea crotti) Date: Fri, 25 Feb 2011 16:35:39 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: References: <4D679E8E.7060403@online.de> <4D67CAF2.3020405@online.de> Message-ID: Uhm even forcing the load of the file python-mode.el doesn't work. But I think I found it, in wisent-python.el there is ;; Try to load python support, but fail silently since it is only used ;; for optional functionality (require 'python nil t) Which if I get it right hides the python-mode function defined before. So should I complain on the cedet list or there is still something that can be done from my side? Strange I never noticed this thing before... From andreas.roehler at online.de Fri Feb 25 16:41:14 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Feb 2011 16:41:14 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: References: <4D679E8E.7060403@online.de> <4D67CAF2.3020405@online.de> Message-ID: <4D67CD9A.2040602@online.de> Am 25.02.2011 16:30, schrieb andrea crotti: > 2011/2/25 Andreas R?hler: >> usually I start here: >> >> https://code.launchpad.net/python-mode >> BTW my components branch is still heavily changed, major changes underway... >> >> Have a look at the thing-at-point utils stuff nonetheless, for me it's a >> rocket....~~~:===> >> >>> For python-mode/python.el good to know, as long as it's sharing and >>> helping and not fighting is not a problem... >>> > > Oh God I found the problem, I think probably after the last update of > cedet I have this not so funny behaviour > When emacs starts I get this: > python-mode is an interactive compiled Lisp function in > `python-mode.el'. > > After I open the first python file it becomes: > "python-mode is an interactive compiled Lisp function in `python.el'. > > (python-mode)" > > So I'm just using the wrong thing but I didn't notice because > "locate-library" also gave me the right file. > > Any way to solve this "conflict" once for all? > Using some function to toggle several branches/modes like this (set-buffer (get-buffer-create "test.py")) (erase-buffer) (when (featurep 'python-mode)(unload-feature 'python-mode t)) (fundamental-mode) (setq py-python-command-args '("-colors" "Linux")) (add-to-list 'load-path NEW-PATH... then load some python-stuff into, call python-mode again. HTH Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ From andreas.roehler at online.de Fri Feb 25 16:53:09 2011 From: andreas.roehler at online.de (=?ISO-8859-1?Q?Andreas_R=F6hler?=) Date: Fri, 25 Feb 2011 16:53:09 +0100 Subject: [Python-mode] highlight bug? In-Reply-To: References: <4D679E8E.7060403@online.de> <4D67CAF2.3020405@online.de> Message-ID: <4D67D065.7040305@online.de> Am 25.02.2011 16:35, schrieb andrea crotti: > Uhm even forcing the load of the file python-mode.el doesn't work. > > But I think I found it, in wisent-python.el there is > ;; Try to load python support, but fail silently since it is only used > ;; for optional functionality > (require 'python nil t) > > Which if I get it right hides the python-mode function defined before. > So should I complain on the cedet list or there is still something that > can be done from my side? Write a blueprint at launchpad and propose cedet-integration. :-) Seriously, have thought at that, it's welcome. Don't know what will happen, if you just comment out that line. Maybe Cedet requires some specific API from python.el? Then an alias to an function from python-mode may help. And so on. Differences are not that numerous AFAIS. Given the blueprint and your interest, your experiences with Cedet might be valid for further development anyway. > Strange I never noticed this thing before... >