Thread: Re: [CEDET-devel] python-mode support
Brought to you by:
zappo
From: Eric L. <er...@si...> - 2011-03-01 22:51:57
|
Hi, I think it makes sense to support a wide array of modes. I'm not that familiar with the question you ask though. Perhaps if you take out the require all together, and run the unit tests we can find out what it is used for. Eric Sent from Samsung tablet Andrea Crotti <and...@gm...> wrote: >Andrea Crotti <and...@gm...> writes: > >> Hi everyone, I realized some days ago that using semantic on python >> code had a side-effect, I was no more using python-mode.el but the >> default python.el. >> >> I found that the problem was given from wisent-python.el, and I think >> I might have found a solution. >> >> Making the python library to load customizable and setting it to >> python-mode seems to work (as the diff below). >> >> Only a few concerns about it: >> - I can't find exactly for what python-mode is used for >> - I'm not sure this is the right way to solve this "issue" and/or it might >> be generalized a bit more. >> >> === modified file 'semantic/wisent/wisent-python.el' >> --- semantic/wisent/wisent-python.el 2011-01-20 21:12:43 +0000 >> +++ semantic/wisent/wisent-python.el 2011-02-26 19:48:31 +0000 >> @@ -44,9 +44,11 @@ >> >> (require 'rx) >> >> -;; Try to load python support, but fail silently since it is only used >> -;; for optional functionality >> -(require 'python nil t) >> +;; try to load python support, failing silently if not found >> +(defcustom semantic-python-mode-backend 'python >> + "Select the used python-mode library, for example 'python, 'python-mode") >> + >> +(require semantic-python-mode-backend nil t) >> >> (require 'semantic-wisent) >> (require 'wisent-python-wy) > >Noone interested in this? >I'll open a blueprint on launchpad otherwise, maybe it's more visible... >The solution I proposed here is surely not the best one but it works >well enough for me. > >------------------------------------------------------------------------------ >Free Software Download: Index, Search & Analyze Logs and other IT data in >Real-Time with Splunk. Collect, index and harness all the fast moving IT data >generated by your applications, servers and devices whether physical, virtual >or in the cloud. Deliver compliance at lower cost and gain new business >insights. http://p.sf.net/sfu/splunk-dev2dev >_______________________________________________ >Cedet-devel mailing list >Ced...@li... >https://lists.sourceforge.net/lists/listinfo/cedet-devel |
From: David E. <de...@ra...> - 2011-03-02 20:48:41
|
Eric Ludlam writes: > Hi, > > I think it makes sense to support a wide array of modes. I'm not that > familiar with the question you ask though. Perhaps if you take out > the require all together, and run the unit tests we can find out what > it is used for. The unit tests work fine without the 'require. I think the only function used is python-send-receive to get the system include path. This has actually bitten me, because the python-mode from Emacs proper doesn't work with Python3, which however is default on my system and therefore let the unit tests hang. I took the liberty to add Jan to the CC, since he might have an idea how to deal with that. The whole python situation under Emacs seems to be a mess anyway... -David |
From: Jan M. <jmo...@un...> - 2011-03-02 21:15:32
Attachments:
python-runtime-include-path.diff
|
On Wed, 2011-03-02 at 21:47 +0100, David Engster wrote: > Eric Ludlam writes: > > Hi, > > > > I think it makes sense to support a wide array of modes. I'm not that > > familiar with the question you ask though. Perhaps if you take out > > the require all together, and run the unit tests we can find out what > > it is used for. > > The unit tests work fine without the 'require. I think the only function > used is python-send-receive to get the system include path. This has > actually bitten me, because the python-mode from Emacs proper doesn't > work with Python3, which however is default on my system and therefore > let the unit tests hang. > > I took the liberty to add Jan to the CC, since he might have an idea how > to deal with that. The whole python situation under Emacs seems to be a > mess anyway... The problem is caused by the attached change which I made a while ago. The goal of that change was to dynamically obtain the Python load-path by querying the interpreter. I tried to write the querying code in a way that would silently fall back to the previous behavior in case python.el was not available. The unit tests works fine without the require because it does not rely on the augmented include path (I think). When the require is removed, the feature test for python fails and the augmentation of the include path does not happen. The only solution I can think of that does not require modifying the python.el shipped with Emacs is checking the Python version in wisent-python.el and only using `python-send-receive' when it is safe. Another possibility is of course reverting the change altogether. However, I would prefer a different solution since I plan doing some omniscient semanticdb stuff based on `python-send-receive'. Hope that helps, Jan |
From: Andrea C. <and...@gm...> - 2011-03-08 08:26:15
|
Jan Moringen <jmo...@un...> writes: > The problem is caused by the attached change which I made a while ago. > The goal of that change was to dynamically obtain the Python load-path > by querying the interpreter. I tried to write the querying code in a way > that would silently fall back to the previous behavior in case python.el > was not available. > > The unit tests works fine without the require because it does not rely > on the augmented include path (I think). When the require is removed, > the feature test for python fails and the augmentation of the include > path does not happen. > > The only solution I can think of that does not require modifying the > python.el shipped with Emacs is checking the Python version in > wisent-python.el and only using `python-send-receive' when it is safe. > > Another possibility is of course reverting the change altogether. > However, I would prefer a different solution since I plan doing some > omniscient semanticdb stuff based on `python-send-receive'. > > Hope that helps, > Jan Well if it can be useful in the future then of course it makes sense. The only problem here is that with this default setting python-mode is overridden and the user doesn't even notice that he's using python.el instead. I had a look and python-send-receive is not that complicated, if you only need one function and not always would not make sense to extract it and add it to cedet instead? It would be great to have a smarter semanticdb for python, but isn't python maybe too dynamic to be well supported? There are great libraries like rope that would enable all sort of nice things. They require something like Pymacs in the middle to communicate but I think that if it would be possible to integrate everything with cedet it would be a great step forward, with refactoring and really nice autocompletion... What do you think? |