Thread: [CEDET-devel] [PATCH] Python 3 support
Brought to you by:
zappo
From: Thomas B. <th...@st...> - 2012-01-29 09:34:58
|
Hello there, I'm German student of Philosophy and Computer Science (yes I know, strange combination…) mainly developing in Python. I found myself yesterday spending another three hours trying to get all kinds of Python-tools-for-Emacs integrated, when I decided that this is just a waste of time and CEDET should be the way to go. So here I am! ;) As a first thing I tweaked a bit on Python 3 integration: $ bzr diff === modified file 'semantic/wisent/wisent-python.el' --- semantic/wisent/wisent-python.el 2011-08-10 17:13:41 +0000 +++ semantic/wisent/wisent-python.el 2012-01-28 21:18:52 +0000 @@ -67,8 +67,15 @@ (accept-process-output (python-proc) 2) (if python-preoutput-result (split-string python-preoutput-result "[\0\n]" t) - (message "Timeout while querying Python for system include path.") - nil)) + (progn + ;; Try a second, Python3k compatible shot + (python-send-string + "import sys; print('_emacs_out ' + '\\0'.join(sys.path))") + (accept-process-output (python-proc) 2) + (if python-preoutput-result + (split-string python-preoutput-result "[\0\n]" t) + (message "Timeout while querying Python for system include path.") + nil)))) (message "Python seems to be unavailable on this system."))) (defcustom-mode-local-semantic-dependency-system-include-path This solution is not very elegant: I don't have much Emacs Lisp programming experience and couldn't come up with a Python one-liner that is compatible with both Python 2 and Python 3. But it seems to work… As far as I understood it the next steps would be to have a better EDE integration and the algorithm semantic uses to find imports doesn't seem to be complete. Anyhow: I don't have no idea how to proceed in an effective manner. That is, not to tweak the `.el' file, restart Emacs and look if things worked out. Do you use some testing framework? Regards, vince |
From: Eric M. L. <eri...@gm...> - 2012-01-29 15:07:02
|
On 01/29/2012 04:34 AM, Thomas Bach wrote: > Hello there, > > I'm German student of Philosophy and Computer Science (yes I know, > strange combination…) mainly developing in Python. I found myself > yesterday spending another three hours trying to get all kinds of > Python-tools-for-Emacs integrated, when I decided that this is just a > waste of time and CEDET should be the way to go. > > So here I am! ;) > > As a first thing I tweaked a bit on Python 3 integration: > > > $ bzr diff > === modified file 'semantic/wisent/wisent-python.el' > --- semantic/wisent/wisent-python.el 2011-08-10 17:13:41 +0000 > +++ semantic/wisent/wisent-python.el 2012-01-28 21:18:52 +0000 Thanks! It seems fine to me, so I checked it in. > As far as I understood it the next steps would be to have a better EDE > integration and the algorithm semantic uses to find imports doesn't seem > to be complete. Anyhow: I don't have no idea how to proceed in an > effective manner. That is, not to tweak the `.el' file, restart Emacs > and look if things worked out. Do you use some testing framework? EDE is a great way to get larger python projects to be able to find includes, etc as you describe. In order to edit your Emacs code and try it without restarting, you can look in the EmacsLisp menu for "evaluate" commands. Use those to make the code you just wrote start running in the current Emacs with no fuss. That should prevent the need to restart. In CEDET, so many giant data structures are created, there are times when a restart is needed (when you modify some core class with new fields) but that is rare. The python support is lacking in tests at the moment, but there are many tests it could participate in. For example, in semantic-ia-utest.el, all you need to do is create a new python file in semantic/tests, annotate that python file with comments, and add the file to the list of tested files in semantic-ia-utest.el. No real Emacs Lisp coding is needed for that. You can look at some of the other files for the comment syntax. There are several kinds of smart completion tests that it will execute. Secondly, there are tests in the tests/ toplevel directory. Python probably doesn't fit into any of the existing test frameworks, so it would be necessary to create a new test type. The cit-android.el is probably one of the easier ones to examine and understand, but you will need to develop a whole new EDE project type for python before you get to that. If you choose to create some sizable patches, you will need to fill out a form to assign your copyrights to the FSF for future inclusion in Emacs. I've attached the form to the end of this email. The package you would be contributing to is CEDET and Emacs. Thanks Eric ---------------------- Please email the following information to fsf...@gn..., and we will send you the assignment form for your past and future changes. Please use your full name as the subject line of the message. [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your snail address here.] [Which files have you changed so far, and which new files have you written so far?] |
From: Yagnesh R. Y. <ya...@li...> - 2012-01-30 00:27:16
|
Hello Eric & Thomas ., I am also interested in helping to improve python(may be FORTRAN if possible) support in CEDET. I would try come up with a possible incomplete list of TODOs in another thread. @Eric , Is it correct assume that its better start from newtrunk branch rather than trunk.? -- YYR |
From: Eric M. L. <eri...@gm...> - 2012-02-05 17:07:13
|
On 01/29/2012 07:26 PM, Yagnesh Raghava Yakkala wrote: > > Hello Eric& Thomas ., > > I am also interested in helping to improve python(may be FORTRAN if > possible) support in CEDET. > > I would try come up with a possible incomplete list of TODOs in another > thread. > > @Eric , > Is it correct assume that its better start from newtrunk branch rather than > trunk.? For now, try patches for new functionality against "trunk" until we get the merge done. Patches preventing newtrunk from working are, of course, best for the newtrunk branch. Thanks! Eric |