Re: python.el
Not easily in detail. Anything I actually contributed I consider OK, obviously. We need to verify that this is ok. When you wrote that code, did you have an employer who could possibly claim copyright on it? If so, do we have a disclaimer from that employer? This is why I ask the period of years during which you worked for that problematical employer, and the period of years during which you worked on the code in python.el. Please answer. We are waiting for you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
In that case, why not remove Python support in Emacs 22.1? We can put it back for 22.2, if and when the legal issues get sorted out. Removing it is drastic. Before doing something drastic, I want to check whether it is really necessary. If I can't get the necessary information, then I will remove it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Not easily in detail. Anything I actually contributed I consider OK, obviously. We need to verify that this is ok. When you wrote that code, did you have an employer who could possibly claim copyright on it? If so, do we have a disclaimer from that employer? This is why I ask the period of years during which you worked for that problematical employer, and the period of years during which you worked on the code in python.el. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
However, 1.40 (2006-08-20) by you is extensive and the changelog says Update to Dave Love's latest version. Was this directly from him? Ahh... I guess my memory failed. We should revert this change, then. Could you do this? I'm short on time these days, so I'll at least wait until Richard decides it's OK. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
On 4/27/07, Stefan Monnier [EMAIL PROTECTED] wrote: While I can imagine myself doing it, I don't remember taking anything from the version of your website. Did anybody else do that? Excluding lines by you, and removing trivial changes to comments and version numbers, the current python.el in HEAD contains the following changes: - 1.13 (2004-05-08), lektu (python-describe-symbol): Pass INTERACTIVE-P argument to `help-setup-xref'. - 1.17 (2004-07-02), RMS (python-beginning-of-statement): Exit the loop if backward-up-list gets error. - 1.21 (2004-11-25), RMS (python-font-lock-syntactic-keywords): Check for escapes in the regexp. (python-quote-syntax): Don't do it here. - 1.23 (2004-12-31), RMS (python-mode): Use mode-require-final-newline. - 1.28 (2005-4-26), RMS (python-mode): Use new name eldoc-documentation-function. - 1.34 (2005-10-18), Masatake YAMATO (python-complete-symbol): Pass the common prefix substring of completion to `display-completion-list'. - 1.49 (2006-9-16), RMS (python-preoutput-filter): Fix arg order to string-match. - 1.50 (2006-10-22), John Wiegley (python-use-skeletons): python-mode was auto-inserting templates (for those with abbrev-mode on), not only by default -- *but without a configuration variable to disable it*. This rendered python-mode completely useless for me, so I have added `python-use-skeletons', which is now off by default. - 1.52 (2006-10-04), RMS (python-indent): Add safe-local-variable prop. - 1.58 (2007-04-16), Chong Yidong (python-end-of-block): Avoid looping forever if python-next-statement fails. All of them are in the tiny category (ten lines or less, excluding whitespace changes), and none seem to be lifted from anywhere (though it is up to the individual authors to confirm, of course). However, 1.40 (2006-08-20) by you is extensive and the changelog says Update to Dave Love's latest version. Was this directly from him? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Juanma Barranquero [EMAIL PROTECTED] writes: On 4/27/07, Stefan Monnier [EMAIL PROTECTED] wrote: While I can imagine myself doing it, I don't remember taking anything from the version of your website. Did anybody else do that? Excluding lines by you, and removing trivial changes to comments and version numbers, the current python.el in HEAD contains the following changes: ... All of them are in the tiny category (ten lines or less, excluding whitespace changes), and none seem to be lifted from anywhere (though it is up to the individual authors to confirm, of course). However, 1.40 (2006-08-20) by you is extensive and the changelog says Update to Dave Love's latest version. Was this directly from him? We could simply revert to the pre-2006-08-20 version and reapply subsequent tiny changes. Will satisfy everybody (including RMS)? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
However, 1.40 (2006-08-20) by you is extensive and the changelog says Update to Dave Love's latest version. Was this directly from him? Ahh... I guess my memory failed. We should revert this change, then. The rest looks good, Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Stefan Monnier [EMAIL PROTECTED] writes: However, 1.40 (2006-08-20) by you is extensive and the changelog says Update to Dave Love's latest version. Was this directly from him? Ahh... I guess my memory failed. We should revert this change, then. Could you do this? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Richard Stallman [EMAIL PROTECTED] writes: Can you show us which changes to python.el we need to remove? Or identify them by which versions they were checked in in? Not easily in detail. Anything I actually contributed I consider OK, obviously. I.e., I'd remove anything just taken from the version on my web site. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Can you show us which changes to python.el we need to remove? Or identify them by which versions they were checked in in? Not easily in detail. Anything I actually contributed I consider OK, obviously. I.e., I'd remove anything just taken from the version on my web site. While I can imagine myself doing it, I don't remember taking anything from the version of your website. Did anybody else do that? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
If it's just the 2006-08-20 stuff: Stefan, is there anyway this can easily be removed and still leave a working python.el? Dave, would that be acceptable to you? Otherwise, our only recourse AFAICS is to remove python.el before the (imminent) release of Emacs 22. I suggest simply removing python.el. We can add it back for Emacs 22.2 if/when the unspecified legal issues get ironed out. To remove Python support is drastic. I won't consider that until we have studied other possible solutions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Glenn Morris [EMAIL PROTECTED] writes: Dave Love wrote: I explained it to rms, but he wouldn't do anything bug reports ^about without patches. I can't parse this. Sorry for the typo. It was installed by Stefan. I can't speak for him, but I imagine since he's the person who installed your python.el initially, and subsequent fixes from you, I don't know what those fixes would be. It hasn't been helpful commenting on things when people have complained, unfortunately. that he got the impression that there was no problem installing updates from your version (which I guess is on the web somewhere?). Yes, since it it's generally useful and recent changes apparently weren't going to get into Emacs. I'm sorry if people complain to you about bugs that aren't your fault. There is nothing in the python.el in CVS Emacs that says bug reports should be sent to you. It lists maintainer as FSF. Sure. It's more an issue that the bugs are there. If something in Emacs does not work, bug reports about it are welcome. I'm afraid they don't seem to be, and I've just given up. If changes in some part of Emacs break another, that's bad, but it can't be fixed if no-one mentions it. Of course. I did a lot of the maintenance for Emacs 21. Anyway, back to the topic at hand: there's a potential legal problem with python.el. Is all the code you wrote for python.el affected, or just the 2006-08-20 changes? Before that, there are no changes from python.el from you until we get to 2004-12-02. Only more recent stuff, I reckon, but I'm not sure exactly what off-hand. Anything I didn't send (including to gnu-Emacs-sources) or install myself is best treated as suspect. If it's just the 2006-08-20 stuff: Stefan, is there anyway this can easily be removed and still leave a working python.el? Dave, would that be acceptable to you? I guess that's OK. It's not me I'm worried about, as legal issues can't damage me. Otherwise, our only recourse AFAICS is to remove python.el before the (imminent) release of Emacs 22. Like two or three years ago? :-(. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Richard Stallman [EMAIL PROTECTED] writes: If not, please could you explain in more detail what you mean? There are potential problems due to my previous employer with things I wrote until I left in April 2006. I'm contractually obliged to inform the FSF about that, whether or not I consider it spurious or actually care about GNU. That sounds like a real issue. Did we install code that you wrote during that time? Yes. That's what I'm concerned about. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Anyway, back to the topic at hand: there's a potential legal problem with python.el. Is all the code you wrote for python.el affected, or just the 2006-08-20 changes? Before that, there are no changes from python.el from you until we get to 2004-12-02. Only more recent stuff, I reckon, but I'm not sure exactly what off-hand. Anything I didn't send (including to gnu-Emacs-sources) or install myself is best treated as suspect. If it's just the 2006-08-20 stuff: Stefan, is there anyway this can easily be removed and still leave a working python.el? Dave, would that be acceptable to you? I guess that's OK. Could you be a little more specific about what the legal problem is? - Did your previous employment contract forbid you from assigning copyright for your Emacs changes, or was it some other restriction? - Are you in fact free to offer the version python.el available on your webpage, or does your employment contract prevent you from distributing and licensing that version under the GPL? (This doesn't affect Emacs directly, but would help clarify things). - How far back do the above restrictions/problems go? Does it affect the 2004-05-06 merge of the Emacs CVS python.el to your python.el, which was initiated by you on the emacs-pretest-bug mailing list? How about earlier or later versions? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
That sounds like a real issue. Did we install code that you wrote during that time? Yes. That's what I'm concerned about. Can you show us which changes to python.el we need to remove? Or identify them by which versions they were checked in in? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
If not, please could you explain in more detail what you mean? There are potential problems due to my previous employer with things I wrote until I left in April 2006. I'm contractually obliged to inform the FSF about that, whether or not I consider it spurious or actually care about GNU. That sounds like a real issue. Did we install code that you wrote during that time? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Glenn Morris [EMAIL PROTECTED] writes: Anyway, back to the topic at hand: there's a potential legal problem with python.el. Is all the code you wrote for python.el affected, or just the 2006-08-20 changes? Before that, there are no changes from python.el from you until we get to 2004-12-02. If it's just the 2006-08-20 stuff: Stefan, is there anyway this can easily be removed and still leave a working python.el? Dave, would that be acceptable to you? Otherwise, our only recourse AFAICS is to remove python.el before the (imminent) release of Emacs 22. I suggest simply removing python.el. We can add it back for Emacs 22.2 if/when the unspecified legal issues get ironed out. What do people think? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Chong Yidong [EMAIL PROTECTED] writes: I suggest simply removing python.el. We can add it back for Emacs 22.2 if/when the unspecified legal issues get ironed out. What do people think? Since python.el is new in Emacs 22, removing it is inconventient, but ok. IIUC, then Dave Love's original python.el does not work with Emacs 22, so we need to ask people to use a different reason Maybe we (who?) could put a copy of the current python.el on emacswiki.org We should add a brief note about it to NEWS (in the About external Lisp packages section): *** NEWS23 Apr 2007 14:07:12 +0200 1.1464 --- NEWS23 Apr 2007 18:19:13 +0200 *** *** 31,38 --- 31,42 Some specific packages that are known to cause problems are: ** Semantic (used by CEDET, ECB, JDEE): upgrade to latest version. + ** cua.el, cua-mode.el: remove old versions. + ** python.el: upgrade to the Emacs 22.1 compatible version available from + http://www.emacswiki.org + * Installation Changes in Emacs 22.1 -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
There are potential problems due to my previous employer with things I wrote until I left in April 2006. I'm contractually obliged to inform the FSF about that, whether or not I consider it spurious or actually care about GNU. Do these potential problems apply also to, e.g., this patch that you sent to emacs-pretest-bug in 2004? http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00055.html From:Dave Love Subject: python.el update Date:Thu, 06 May 2004 17:46:33 +0100 These changes to python.el are relative to a previous revision (before one or more rounds of compilation changes) and won't now apply cleanly, but I'm not currently in a position to merge and test them. They rely on a new file of Python code living in `etc' (also attached). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Glenn Morris [EMAIL PROTECTED] writes: Maybe this message is meant for some specific recipients who will already know what this is about. I explained it to rms, but he wouldn't do anything bug reports without patches. I doubt anyone else can say anything useful unless they're privy to legal advice, but I haven't been asked for details. Why are you querying this? Can you give legal advice? If not, please could you explain in more detail what you mean? There are potential problems due to my previous employer with things I wrote until I left in April 2006. I'm contractually obliged to inform the FSF about that, whether or not I consider it spurious or actually care about GNU. The python.el in CVS Emacs is the one you submitted to gnu-emacs-sources here: ?? It's clearly substantially different. The original surely won't even work in the development Emacs. Another fix: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-03/msg00441.html How could that be a copyright issue? I didn't supply any code, on purpose. The only other sizable change from you for python.el seems to be from 2006-08-20. I can't find any mail about this. Is this one the problem? There's a changelog entry from then with my name on it, but it isn't mine, which should be a concern anyway. Some or all of that addition is problematic and I haven't checked any subsequent changes. I'm asking why it and anything else was grabbed and put in without consulting me and whether it's clear there's no problem. (It's pretty annoying to have the code forked and then have people complain to me about bugs, but I'm sure I won't get anywhere on that.) There are two long threads about python.el from August 2006 that start here and here: http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00353.html http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00758.html I haven't read them; are they relevant? Here are some assignment-related comments from Ken Manheimer: http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00753.html I don't think that's necessary -- see the python.el commentary, which he obviously hasn't read. However, my original compilation mode support was broken by subsequently changes in the development Emacs, and I gave up trying to track the general breakage to python.el some time ago. Perhaps it no longer works, unlike the Emacs 21 version I use. Anyhow, that's a side issue that I don't suppose people are interested in hearing about. python.el was done partly because we couldn't get an assignment for python-mode.el and because the maintainers wouldn't accept Emacs-specific fixes. I wouldn't have written more if I thought it was going to be pulled in with potential legal problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Dave Love wrote: I explained it to rms, but he wouldn't do anything bug reports without patches. I can't parse this. I doubt anyone else can say anything useful unless they're privy to legal advice, but I haven't been asked for details. Why are you querying this? Can you give legal advice? I queried this because you sent it to the emacs-pretest-bug mailing list, which is not rms's personal mail account, and I had no clue what you meant, nor could I find anything in the list archives. I got the impression your email was for a specific target, hence the first sentence of my reply. Since rms often takes a day or so to reply, I hoped to speed things along my getting more info. I cannot give legal advice. There are potential problems due to my previous employer with things I wrote until I left in April 2006. I'm contractually obliged to inform the FSF about that, whether or not I consider it spurious or actually care about GNU. I for one am grateful to you for informing us. The python.el in CVS Emacs is the one you submitted to gnu-emacs-sources here: ?? It's clearly substantially different. The original surely won't even work in the development Emacs. My intended meaning was in CVS Emacs is [derived from] the one... Another fix: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-03/msg00441.html How could that be a copyright issue? I didn't supply any code, on purpose. I had no idea what your point was, so I just dredged up all discussions about python.el, in an attempt to speed things along. There's a changelog entry from then with my name on it, but it isn't mine, which should be a concern anyway. Some or all of that addition is problematic and I haven't checked any subsequent changes. I'm asking why it and anything else was grabbed and put in without consulting me and whether it's clear there's no problem. It was installed by Stefan. I can't speak for him, but I imagine since he's the person who installed your python.el initially, and subsequent fixes from you, that he got the impression that there was no problem installing updates from your version (which I guess is on the web somewhere?). (It's pretty annoying to have the code forked and then have people complain to me about bugs, but I'm sure I won't get anywhere on that.) I'm sorry if people complain to you about bugs that aren't your fault. There is nothing in the python.el in CVS Emacs that says bug reports should be sent to you. It lists maintainer as FSF. There are two long threads about python.el from August 2006 that start here and here: http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00353.html http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00758.html I haven't read them; are they relevant? Probably not. I guess these discussions might be what prompted Stefan to check for updates to your python.el. However, my original compilation mode support was broken by subsequently changes in the development Emacs, and I gave up trying to track the general breakage to python.el some time ago. Perhaps it no longer works, unlike the Emacs 21 version I use. Anyhow, that's a side issue that I don't suppose people are interested in hearing about. If something in Emacs does not work, bug reports about it are welcome. If changes in some part of Emacs break another, that's bad, but it can't be fixed if no-one mentions it. Anyway, back to the topic at hand: there's a potential legal problem with python.el. Is all the code you wrote for python.el affected, or just the 2006-08-20 changes? Before that, there are no changes from python.el from you until we get to 2004-12-02. If it's just the 2006-08-20 stuff: Stefan, is there anyway this can easily be removed and still leave a working python.el? Dave, would that be acceptable to you? Otherwise, our only recourse AFAICS is to remove python.el before the (imminent) release of Emacs 22. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
What's the reason for disregarding my legal concerns about that work? Maybe this message is meant for some specific recipients who will already know what this is about. If not, please could you explain in more detail what you mean? Precisely which work has potential legal concerns? I would also like to know the answer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
python.el
I found that you're distributing a version of python.el that includes work I did a couple of years ago (some of which seems to have been somewhat broken in the process). What's the reason for disregarding my legal concerns about that work? Apart from the legal issues it's bizarre the way you reject so many improvements and then either put them in two or three years later or have others reimplement them or something very similar. Apart from wasting the original effort, it can't encourage people you do still approve of to contribute if they see that happening. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Dave Love wrote: I found that you're distributing a version of python.el that includes work I did a couple of years ago (some of which seems to have been somewhat broken in the process). What's the reason for disregarding my legal concerns about that work? Maybe this message is meant for some specific recipients who will already know what this is about. If not, please could you explain in more detail what you mean? Precisely which work has potential legal concerns? The python.el in CVS Emacs is the one you submitted to gnu-emacs-sources here: http://lists.gnu.org/archive/html/gnu-emacs-sources/2004-01/msg00032.html Here you ask why it's not installed yet: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-04/msg3.html Here you supply some updates, installed 2004-05-06 http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00055.html Another fix: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-03/msg00441.html The only other sizable change from you for python.el seems to be from 2006-08-20. I can't find any mail about this. Is this one the problem? There are two long threads about python.el from August 2006 that start here and here: http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00353.html http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00758.html Here are some assignment-related comments from Ken Manheimer: http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00753.html ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: binding for RET in python.el
In python-mode.el RET does a newline-and-indent, and IMHO it makes a lot sense for python code. Is there any reason not to do the same for python.el? It would be incompatible with a basic Emacs convention. I don't like the idea of such changes in basic commands such as RET. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: binding for RET in python.el
Stefan Monnier [EMAIL PROTECTED] writes: I got this comment from users that transitioned from using python-mode.el with emacs-21 to python.el from emacs-22. In python-mode.el RET does a newline-and-indent, and IMHO it makes a lot sense for python code. Is there any reason not to do the same for python.el? It makes sense for other modes as well. In Emacs it's normally considered a preference which users can choose by doing something like: (global-set-key ?\r 'newline-and-indent) or by hitting LFD (i.e. C-j) instead of RET. Now, that doesn't mean that it's necessarily wrong for a major mode to explicitly bind RET to newline-and-indent, but that it needs to be justified by an argument that basically says that if even if a user generally prefers using just `newline' in all other major modes, he'll probably want to use `newline-and-indent' in python.el. I don't use Python myself, so I can't really judge, but by the looks of it I see nothing that makes Python special in this regard (I know about the indentation-sensitive syntax, but it's pretty common to consider misindentation to be a (minor) bug in other languages as well (even though the compiler won't detect it)). IMO in the particular case of python binding RET to newline-and-indent makes sense. I use python, and after a few days of having newline-and-indent bound to RET I can conclude that it feels much better. Another argument is that python-mode.el does this by default, so the python users have come to expect it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: binding for RET in python.el
On 4/27/06, Dan Nicolaescu [EMAIL PROTECTED] wrote: Another argument is that python-mode.el does this by default, so the python users have come to expect it. Since python-mode.el did not seem to have come with emacs, it could do all sort of bizarre things that are undesirable... it's very common that a lot of dodgy behavior gets cleaned up when a package is included in Emacs proper. -Miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: binding for RET in python.el
IMO in the particular case of python binding RET to newline-and-indent makes sense. I use python, and after a few days of having newline-and-indent bound to RET I can conclude that it feels much better. To me this sounds like you're saying that this default is good for *you*, not that this default is good for Python. Try to use this binding globally, you'll probably like it. Another argument is that python-mode.el does this by default, so the python users have come to expect it. One of the things we try to do when we integrate packages in Emacs is to try and make sure there is some minimum amount of consistency between those packages by following some loose conventions. The fact that some related major mode has chosen a different default only matters if it doesn't go against those conventions. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: python-describe-symbol fix for python.el and emacs.py]
From: Steven Huwig [EMAIL PROTECTED] Date: Wed, 21 Sep 2005 20:46:13 -0400 To: emacs-pretest-bug@gnu.org Subject: python-describe-symbol fix for python.el and emacs.py Using the copy of emacs.py I just pulled from CVS, the following behavior occurs: from Tkinter import * emacs.ehelp(Frame) no Python documentation found for 'Frame' None If you add the optional globals and locals parameters to the eval call in emacs.ehelp(), and to the invoking python-describe-symbol function in python.el, emacs.ehelp() will find the help in these cases. Thanks, I installed these changes. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
python-describe-symbol fix for python.el and emacs.py
Hello, Using the copy of emacs.py I just pulled from CVS, the following behavior occurs: from Tkinter import * emacs.ehelp(Frame) no Python documentation found for 'Frame' None If you add the optional globals and locals parameters to the eval call in emacs.ehelp(), and to the invoking python-describe-symbol function in python.el, emacs.ehelp() will find the help in these cases. Thanks, Steven Huwig --- python.el 27 Aug 2005 14:38:21 - 1.32 +++ python.el 12 Sep 2005 00:47:44 - @@ -1341,7 +1341,7 @@ nil nil symbol (if (equal symbol ) (error No symbol)) (let* ((func `(lambda () - (comint-redirect-send-command (format emacs.ehelp(% S)\n + (comint-redirect-send-command (format emacs.ehelp(% S, globals(), locals())\n ,symbol) *Help* nil ;; Ensure we have a suitable help buffer. --- emacs.py24 Aug 2005 11:32:07 - 1.4 +++ emacs.py12 Sep 2005 00:48:42 - @@ -82,11 +82,11 @@ except: print '_emacs_out ()' -def ehelp (name): +def ehelp (name, g, l): Get help on string NAME. First try to eval name for, e.g. user definitions where we need the object. Otherwise try the string form. -try: help (eval (name)) +try: help (eval (name, g, l)) except: help (name) def eimport (mod, dir): ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
(defun python-preoutput-filter (s) `comint-preoutput-filter-functions' function: ignore prompts not at bol. (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) I see you've reverted to the basic code and thus removed the while loop I had added. I guess it's OK so long as we know we'll only be waiting for one line of output at a time. Also the loop was already missing before anyway. I installed a slightly different patch (halfway between yours and mine). Can you try it? Your code special-cased the case when the emacs_out line is cut, but what is really happenning is that we may receive Python's output in chunks of arbitrary sizes: from one-byte at a time to several lines at a time (depending on many different factors), so the problem exists for all kinds of output. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
On Mar 27, 2005, at 9:50 AM, Stefan Monnier wrote: I couldn't get your patch to work. However, I did see what was going on and I managed to write my own patch. I don't know if this could break anything else, but it does fix my OS X completion problems. Thanks, I'll install it later. From my limited knowledge, it looks as if the process communication code for OS X will return data in 1024-character blocks, but for better-supported platforms, it will read until the end of line? No, but maybe the limit is 4096 is other platforms. Thanks for helping us fix this issue. Glad to help. This makes using Emacs to edit PyObjC code *much* easier. Thank you for helping me through the debugging process, and thank you, Dave Love, for working on python.el. Thanks, Steven Huwig ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
In the shell, the text wraps around to the next line, which is acceptable. This is not the case for Emacs windows split vertically with C-x 3 or ECB. Try (setq truncate-partial-width-windows nil) On my system, the emacs.py rlcompleter interface works correctly and outputs a string, but python.el does not successfully read this string and reports Can't find completion for os. Can you try to debug this? Try the following: - C-h f python-symbol-completions RET - middle-click on python.el to jump to the definition of the function - C-u C-M-x so as to redefine the function with edebug-instrumentation - now go to the python-mode buffer and redo the os.[TAB] - you should now hopefully be in edebug-mode in python.el where you can advance step by step with SPC or n (it's not the same steps). See the elisp manual for more info about edebug. Another thing you can do is to change: (condition-case () (car (read-from-string (python-send-receive (format emacs.complete(%S) symbol (error nil into (condition-case err (car (read-from-string (python-send-receive (format emacs.complete(%S) symbol (error (message Error in completion: %S err) nil so you'll get more information about the error you get (the error is most likely in read-from-string. E.g. a missing close-paren, ...) Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue (was Re: Suggestion for python.el and emacs.py)
On Mar 26, 2005, at 12:51 PM, Steven Huwig wrote: That had no effect on the behavior. I guess it must actually be an issue with the size of the incoming data vs. some buffer size in the C code ... does this sound plausible? I will write up some scripts to incrementally generate and test Python attrs and see what the maximum working length is, for lack of any insight into the root cause. After some preliminary experimentation, it appears that the issue with python-send-receive first manifests itself when the length of _emacs_out exceeds a value in the 1000-character range... it succeeds when the string is 980 characters long but fails when the string is 1060. Thanks, Steve ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
On Mar 26, 2005, at 5:10 PM, Stefan Monnier wrote: Maybe you could add a `message' at the beginning of python-preoutput-filter, to see what the process filter actually receives. Or maybe even at the beginning of comint-output-filter. Stefan Curiouser and curiouser. I put a message in python-preoutput-filter that echoes its parameter as you suggest. Looking at the contents of my messages buffer after attempting the completion for os., the Can't find completion message from the python completion routine happens after precisely 1024 characters are read. Furthermore it looks like the data coming from the process is interrupted every 1024 characters. _emacs_out ( os.EX_CANTCREAT os.EX_CONFIG os.EX_DATAERR os.EX_IOERR os.EX_NOHOST os.EX_NOINPUT os.EX_NOPERM os.EX_NOUSER os.EX_OK os.EX_OSERR os.EX_OSFILE os.EX_PROTOCOL os.EX_SOFTWARE os.EX_TEMPFAIL os.EX_UNAVAILABLE os.EX_USAGE os.F_OK os.NGROUPS_MAX os.O_APPEND os.O_CREAT os.O_EXCL os.O_NDELAY os.O_NOCTTY os.O_NOFOLLOW os.O_NONBLOCK os.O_RDONLY os.O_RDWR os.O_TRUNC os.O_WRONLY os.P_NOWAIT os.P_NOWAITO os.P_WAIT os.R_OK os.TMP_MAX os.UserDict os.WCOREDUMP os.WEXITSTATUS os.WIFEXITED os.WIFSIGNALED os.WIFSTOPPED os.WNOHANG os.WSTOPSIG os.WTERMSIG os.WUNTRACED os.W_OK os.X_OK os._Environ os.__all__ os.__doc__ os.__file__ os.__name__ os._copy_reg os._execvpe os._exists os._exit os._get_exports_list os._make_stat_result os._make_statvfs_result os._pickle_stat_result os._pickle_statvfs_result os._spawnvef os.abort os.access os.altsep os.chdir os.chmod os.chown os.chroot os.clos Can't find completion for os. e os.confstr os.confstr_names os.ctermid os.curdir os.defpath os.dup os.dup2 os.environ os.error os.execl os.execle os.execlp os.execlpe os.execv os.execve os.execvp os.execvpe os.extsep os.fchdir os.fdopen os.fork os.forkpty os.fpathconf os.fstat os.fsync os.ftruncate os.getcwd os.getcwdu os.getegid os.getenv os.geteuid os.getgid os.getgroups os.getloadavg os.getlogin os.getpgid os.getpgrp os.getpid os.getppid os.getuid os.isatty os.kill os.killpg os.linesep os.link os.listdir os.lseek os.lstat os.major os.makedev os.makedirs os.minor os.mkdir os.mkfifo os.mknod os.name os.nice os.open os.openpty os.pardir os.path os.pathconf os.pathconf_names os.pathsep os.pipe os.popen os.popen2 os.popen3 os.popen4 os.putenv os.read os.readlink os.remove os.removedirs os.rename os.renames os.rmdir os.sep os.setegid os.seteuid os.setgid os.setgroups os.setpgid os.setpgrp os.setregid os.setreuid os.setsid os.setuid os.spawnl os.spawnle os.spawnlp os.spawnlpe os.spawnv os.spawnve os.spawnvp os.spawnvpe os.stat os.stat_float_times os.stat_result os.statvfs_result os.strerror os.symlink os.sys os.sysconf os.sysconf_names os.system os.tcgetpgrp os.tcsetpgrp os.tempnam os.times os.tmpfile os.tmpnam os.ttyname os.umask os.uname os.unlink os.unsetenv os.utime os.wait os.waitpid os.walk os.write os.__class__ os.__class__ os.__delattr__ os.__dict__ os.__doc__ os.__getattribute__ os.__hash__ os.__init__ os.__new__ os.__reduce__ os.__reduce_ex__ os.__repr__ os.__setattr__ os.__str__ os.__class__ os.__delattr__ os.__doc__ os.__getattribute__ os.__hash__ os.__init__ os.__new__ os.__reduce__ os.__reduce_ex__ os.__repr__ os.__setattr__ os.__str__ ) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
Curiouser and curiouser. I put a message in python-preoutput-filter that echoes its parameter as you suggest. Looking at the contents of my messages buffer after attempting the completion for os., the Can't find completion message from the python completion routine happens after precisely 1024 characters are read. Furthermore it looks like the data coming from the process is interrupted every 1024 characters. Oh, I think I know what's happening. Can you try the patch below? I haven't been able to really test it because in my case the input string is always just one complete line, so the looping and the python-preoutput-leftover aren't used. Stefan --- orig/lisp/progmodes/python.el +++ mod/lisp/progmodes/python.el @@ -1098,28 +1098,46 @@ (defvar python-preoutput-continuation nil If non-nil, funcall this when `python-preoutput-filter' sees `_emacs_ok'.) +(defvar python-preoutput-leftover nil) + ;; Using this stops us getting lines in the buffer like ;; ... ... ;; Also look for (and delete) an `_emacs_ok' string and call ;; `python-preoutput-continuation' if we get it. (defun python-preoutput-filter (s) `comint-preoutput-filter-functions' function: ignore prompts not at bol. - (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) - string-end)) - s) - (/= (let ((inhibit-field-text-motion t)) - (line-beginning-position)) - (point))) -) - ((string= s _emacs_ok\n) -(when python-preoutput-continuation - (funcall python-preoutput-continuation) - (setq python-preoutput-continuation nil)) -) - ((string-match _emacs_out \\(.*\\)\n s) -(setq python-preoutput-result (match-string 1 s)) -) - (t s))) + (when python-preoutput-leftover +(setq s (concat python-preoutput-leftover s)) +(setq python-preoutput-leftover nil)) + (let ((res )) +(while ( (length s) 0) + (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) + string-end)) + s) + (/= (let ((inhibit-field-text-motion t)) + (line-beginning-position)) + (point))) +(setq s nil)) + ((string-match \\`_emacs_ok\n s) +(setq s (substring s (match-end 0))) +(when python-preoutput-continuation + (funcall python-preoutput-continuation) + (setq python-preoutput-continuation nil))) + ((string-match \\`_emacs_out \\(.*\\)\n? s) +(setq python-preoutput-result + (concat python-preoutput-result (match-string 1 s))) +(setq s (substring s (match-end 0))) +(if (/= (match-end 1) (match-end 0)) +(set (make-local-variable 'python-preoutput-leftover) + _emacs_out ))) + ((or (eq t (compare-strings s nil nil _emacs_ok\n nil (length s))) +(eq t (compare-strings s nil nil _emacs_out nil (length s +(set (make-local-variable 'python-preoutput-leftover) s) +(setq s nil)) + ((string-match \\`.*\n? s) +(setq res (concat res (match-string 0 s))) +(setq s (substring s (match-end 0)) +res)) ;;;###autoload (defun run-python (optional cmd noshow) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
On Mar 26, 2005, at 8:05 PM, Stefan Monnier wrote: Curiouser and curiouser. I put a message in python-preoutput-filter that echoes its parameter as you suggest. Looking at the contents of my messages buffer after attempting the completion for os., the Can't find completion message from the python completion routine happens after precisely 1024 characters are read. Furthermore it looks like the data coming from the process is interrupted every 1024 characters. Oh, I think I know what's happening. Can you try the patch below? I haven't been able to really test it because in my case the input string is always just one complete line, so the looping and the python-preoutput-leftover aren't used. I couldn't get your patch to work. However, I did see what was going on and I managed to write my own patch. I don't know if this could break anything else, but it does fix my OS X completion problems. From my limited knowledge, it looks as if the process communication code for OS X will return data in 1024-character blocks, but for better-supported platforms, it will read until the end of line? Thanks, Steven Huwig --- python.el 9 Feb 2005 15:50:36 - 1.24 +++ python.el 27 Mar 2005 06:48:31 - @@ -1098,6 +1098,8 @@ (defvar python-preoutput-continuation nil If non-nil, funcall this when `python-preoutput-filter' sees `_emacs_ok'.) +(defvar python-preoutput-leftover nil) + ;; Using this stops us getting lines in the buffer like ;; ... ... ;; Also look for (and delete) an `_emacs_ok' string and call @@ -1105,21 +1107,33 @@ (defun python-preoutput-filter (s) `comint-preoutput-filter-functions' function: ignore prompts not at bol. (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) - string-end)) - s) - (/= (let ((inhibit-field-text-motion t)) - (line-beginning-position)) - (point))) - ) - ((string= s _emacs_ok\n) - (when python-preoutput-continuation - (funcall python-preoutput-continuation) - (setq python-preoutput-continuation nil)) - ) - ((string-match _emacs_out \\(.*\\)\n s) - (setq python-preoutput-result (match-string 1 s)) - ) - (t s))) + string-end)) +s) + (/= (let ((inhibit-field-text-motion t)) +(line-beginning-position)) + (point))) + ) +((string= s _emacs_ok\n) + (when python-preoutput-continuation + (funcall python-preoutput-continuation) + (setq python-preoutput-continuation nil)) + ) +((string-match _emacs_out \\(.*\\)\n s) + (setq python-preoutput-result (match-string 1 s)) + ) +((string-match _emacs_out \\(.*\\) s) + (setq python-preoutput-leftover (match-string 1 s)) + ) +(( (length python-preoutput-leftover) 0) + (cond + ((string-match \\(.*\\)\n s) + (setq python-preoutput-result + (concat python-preoutput-leftover (match-string 1 s))) + (setq python-preoutput-leftover nil)) + (t (setq python-preoutput-leftover + (concat python-preoutput-leftover s + ) +(t s))) ;;;###autoload (defun run-python (optional cmd noshow) @@ -1360,6 +1374,8 @@ (python-send-string string) (setq python-preoutput-result nil) (accept-process-output proc 5) +(while ( (length python-preoutput-leftover) 0) + (accept-process-output proc 5)) python-preoutput-result)) ;; Fixme: try to make it work with point in the arglist. Also, is ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
Stefan [EMAIL PROTECTED] writes: Also it would be better to fix the bugs in python.el... Which bugs? I don't remember them all, but apparently the sub-process fails on Windows and someone just complained to me about an instance where indentation failed where a word boundary should be a symbol boundary. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
Steven Huwig [EMAIL PROTECTED] writes: Anyhow, I don't think it's appropriate for Emacs to override the user's Python startup like that. If nothing else in the Python environment is being overridden or having its behavior changed by Emacs, I agree. That's the idea, apart from needing to import emacs.py. Perhaps a line in documentation or a customization variable would suffice. I have used Emacs and Python for some time and never really realized that pprint would solve my line wrap problems so easily until the question was raised for the dozenth time by the dozenth acquaintance. I'd like to save others the time to research the same question while making interacting with Python a bit nicer out-of-the-box in Emacs. I don't see what this has to do with Emacs. Why would you want that in an Emacs sub-process but not interacting with python from the shell? I do notice that completion doesn't seem to work if an item's list of attributes is too long (try completing os.M-Tab). Is that one of these bugs, or have I managed to overlook something? What is the problem in that case? I don't see it on a quick try. I only just discovered python.el recently, having used python-mode and being frustrated by it at various points. I'm glad if it's useful. It's a pity it requires an unreleased Emacs. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Dave Love] python.el: block is ended prematurely
python.el ends the current block if a line starts with return. However, it doesn't checkt whether this is followed with _. So, if I write return_count = 4 python.el closes the current block wrongly. I've installed Dave's suggestion in Emacs-CVS. Can you confirm that it fixes your bug? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Dave Love] python.el: block is ended prematurely
Hallchen! Stefan Monnier [EMAIL PROTECTED] writes: python.el ends the current block if a line starts with return. However, it doesn't checkt whether this is followed with _. So, if I write return_count = 4 python.el closes the current block wrongly. I've installed Dave's suggestion in Emacs-CVS. Can you confirm that it fixes your bug? Yes, it does. Thanks to both of you! Tsch, Torsten. -- Torsten Bronger, aquisgrana, europa vetus ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
Stefan Monnier [EMAIL PROTECTED] writes: I don't myself use Python, so I don't know what such a patch could break. Can someone who's used Python (and the new pyhton-mode) confirm that this change is a good idea? I notice that CVS Emacs now has a python mode. Here is a small patch to etc/emacs.py to make the Python shell display objects in a readable format (i.e. not putting long lists into a single line but rather adding newlines where appropriate). Presumably Eldoc and completion will fail if the value is broken (in which case I guess they should protect against that hook being used). Anyhow, I don't think it's appropriate for Emacs to override the user's Python startup like that. Also it would be better to fix the bugs in python.el... ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
I notice that CVS Emacs now has a python mode. Here is a small patch to etc/emacs.py to make the Python shell display objects in a readable format (i.e. not putting long lists into a single line but rather adding newlines where appropriate). Presumably Eldoc and completion will fail if the value is broken (in which case I guess they should protect against that hook being used). Anyhow, I don't think it's appropriate for Emacs to override the user's Python startup like that. Sounds right, thanks. Also it would be better to fix the bugs in python.el... Which bugs? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Dave Love] python.el: block is ended prematurely
---BeginMessage---
You wrote:
Hallchen!
python.el ends the current block if a line starts with return.
However, it doesn't checkt whether this is followed with _. So,
if I write
return_count = 4
python.el closes the current block wrongly.
Tsch,
Torsten.
Could you report it to emacs-pretest-bug@gnu.org, please. I can't
make changes. There are some other things that need fixing for
python.el which I haven't been able to get done, but it is worth a
try...
I fixed it like this: First modify rx.el to add `symbol-start' and
`symbol-end' for \_ and \_. (It is a bug that they aren't
included.) Then use `symbol-end' instead of `word-end' in function
`python-close-block-statement-p'. (In my version I've used
symbol-{start,end} in some other places, like the font-lock keywords.)
---End Message---
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
