CEDET

On 10/12/2012 05:49 PM, Daimrod wrote:
> Hi,
>
> I'm using the latest emacs (compiled from git) and I use python-mode
> (from bzr) instead of the built-in mode python.el.
>
> I've encountered this bug[1], however, `python-proc' is now deprecated
> and should be replaced by `python-shell-internal-get-or-create-process'.
> And that's cool, because python-mode uses the same name.
>
> Could semantic use `python-shell-internal-get-or-create-process' instead
> of the old `python-proc'?
>
> It just need to be replaced in
> wisent/python.el::semantic-python-get-system-include-path
>
> [1] http://comments.gmane.org/gmane.emacs.cedet/5512

I think CEDET integrated with Emacs should use whatever the right thing 
there is.  For CEDET on sourceforge, if older emacsen still use the old 
python shell version, then it will need to be able to check for both cases.

I am not a python expert.  If someone poses a simple patch, that would 
be great.

Eric

"Eric M. Ludlam" <ericludlam@...> writes:

> On 10/12/2012 05:49 PM, Daimrod wrote:
>> Hi,
>>
>> I'm using the latest emacs (compiled from git) and I use python-mode
>> (from bzr) instead of the built-in mode python.el.
>>
>> I've encountered this bug[1], however, `python-proc' is now deprecated
>> and should be replaced by `python-shell-internal-get-or-create-process'.
>> And that's cool, because python-mode uses the same name.
>>
>> Could semantic use `python-shell-internal-get-or-create-process' instead
>> of the old `python-proc'?
>>
>> It just need to be replaced in
>> wisent/python.el::semantic-python-get-system-include-path
>>
>> [1] http://comments.gmane.org/gmane.emacs.cedet/5512
>
> I think CEDET integrated with Emacs should use whatever the right thing 
> there is.  For CEDET on sourceforge, if older emacsen still use the old 
> python shell version, then it will need to be able to check for both cases.
>
> I am not a python expert.  If someone poses a simple patch, that would 
> be great.
>
> Eric

Hum, you're right, I didn't think about retro-compatibility. So I guess
the right thing™ would be to add an alias to python-mode.

(defalias 'python-proc 'python-shell-internal-get-or-create-process)

That's what I use currently in my .emacs.

'daimrod' writes:
> Hum, you're right, I didn't think about retro-compatibility. So I guess
> the right thing™ would be to add an alias to python-mode.
>
> (defalias 'python-proc 'python-shell-internal-get-or-create-process)
>
> That's what I use currently in my .emacs.

This little Python issue has haunted us for years. I've now started a
thread on Emacs-devel which hopefully will settle this issue once and
for all. The Python situation on Emacs is really... complicated.

-David

David Engster <deng@...> writes:
> This little Python issue has haunted us for years. I've now started a
> thread on Emacs-devel which hopefully will settle this issue once and
> for all. The Python situation on Emacs is really... complicated.
>
> -David

Thank you for your attention, I'll follow the thread.

'daimrod' writes:
> David Engster <deng@...> writes:
>> This little Python issue has haunted us for years. I've now started a
>> thread on Emacs-devel which hopefully will settle this issue once and
>> for all. The Python situation on Emacs is really... complicated.
>>
>> -David
>
> Thank you for your attention, I'll follow the thread.

I've now pushed a change that uses python-shell-internal-send-string. I
have no idea whether that also works for the external
python-mode. However, I'm not fond of supporting two different python
modes in the first place. The Python support in CEDET is lacking anyway,
so I'd rather not make it more complicated.

We can apply small changes if necessary (for example regarding the
initial require statement), but otherwise python-mode should provide the
necessary aliases, or advice CEDET functions as necessary.

-David

I wish I had the time to merge the two python modes into one so that we
all use a single python mode rather than two.  I never seem to be able
to find that time.  Below I provide my past efforts to support both in
my environment and explain why I just gave up.

First I created a boolean flag to switch between the two:

  (defvar kimr-use-python-mode nil
    "If non-nil, then enable the use of python-mode.el from python.org.
  Default is nil which means to use the built-in python.el.")

Second I created an ELPA package called python-mode consisting of a
few files:


    $ cd ~/elpa-kimr/python-mode
    $ ls -l
    total 284
    -rw-r--r-- 1 kimr kimr  85097 Oct 10  2011 doctest-mode.el
    -rw-r--r-- 1 kimr kimr    786 Oct 10  2011 NEWS
    -rw-r--r-- 1 kimr kimr   1581 Oct 10  2011 pycomplete.el
    -rw-r--r-- 1 kimr kimr   3274 Oct 10  2011 pycomplete.py
    -rw-r--r-- 1 kimr kimr 169873 Apr 20 17:11 python-mode.el
    -rw-rw-r-- 1 kimr kimr   5148 Mar  2  2012 pyton-mode.texi
    -rw-r--r-- 1 kimr kimr    316 Oct 10  2011 README
    drwxr-xr-x 3 kimr kimr   4096 Oct 10  2011 website
    $

Also I created another package consisting of a few other python packages
that I downloaded:

    $ cd ~/elpa-kimr/python-utils/
    $ ls -l
    total 3436
    -rw-r--r-- 1 kimr kimr   20856 Oct 10  2011 ipython.el
    -rw-r--r-- 1 kimr kimr 3421663 Oct 10  2011 pylookup.db
    -rw-r--r-- 1 kimr kimr    9137 Oct 10  2011 pylookup.el
    -rwxr-xr-x 1 kimr kimr    7282 Oct 10  2011 pylookup.py
    -rw-r--r-- 1 kimr kimr   33613 Oct 10  2011 pymacs.el
    -rw-r--r-- 1 kimr kimr    4083 Oct 10  2011 python-pep8.el
    -rw-r--r-- 1 kimr kimr    4170 Oct 10  2011 python-pylint.el

Third I use this flag to do things differently for the two modes.
For example I turn on python-mode and python-utils packages only if I'm
using python-mode.el:

  (when kimr-use-python-mode
    (kimr-package-activate 'python-mode))

  (when kimr-use-python-mode
    (kimr-package-activate 'python-utils))

kimr-package-activate is a thin wrapper which adds an item to
package-load-list then calls (package-initialize).
Some, if not all, of the files in python-utils above work only for
python-mode.el, but not for the built-in python.el.
That is why I turn on these only when I'm using python-mode.el.

Also you have to be very careful to prevent loading the built-in
python.el if you are using python-mode.el, because the two define many
functions with the same names, but which behave differently.
So I tried the following:

  ;; Autoloading for python-mode does not work, because of conflict with
built-in
  ;; python.el.  Also something within emacs seems to have (require
'python) so
  ;; that if 'python-mode is loaded first, then (require 'python) later on
  ;; clobbers python-mode.
  (when kimr-use-python-mode
    (require 'python-mode)
    (kimr-disable-built-in-python-mode))

  (defun kimr-disable-built-in-python-mode ()
    "Call this to improve chances of lisp/progmodes/python.el not getting
loaded
  accidentally.  This should be called after loading python-mode.el."
    (defun jython-mode ())
    (defun python-after-info-look ())
    (defun python-backspace (arg))
    (defun python-beginning-of-block (&optional arg))
    (defun python-check (command))
    (defun python-describe-symbol (symbol))
    (defun python-electric-colon (arg))
    (defun python-end-of-block (&optional arg))
    (defun python-expand-template (name))
    (defun python-fill-paragraph (&optional justify))
    (defun python-find-function (name))
    (defun python-find-imports ())
    (defun python-guess-indent ())
    (defun python-indent-line ())
    (defun python-load-file (file-name))
    (defun python-mark-block ())
    (defun python-next-statement (&optional count))
    (defun python-pdbtrack-toggle-stack-tracking (arg))
    (defun python-previous-statement (&optional count))
    (defun python-send-buffer ())
    (defun python-send-defun ())
    (defun python-send-region (start end))
    (defun python-send-region-and-go (start end))
    (defun python-send-string (string))
    (defun python-set-proc ())
    (defun python-setup-brm ())
    (defun python-shell (&optional argprompt))
    (defun python-shift-left (start end &optional count))
    (defun python-shift-right (start end &optional count))
    (defun python-switch-to-python (eob-p))
    (defun python-toggle-shells (arg))
    (defun run-python (&optional cmd noshow new))
    (defun turn-off-pdbtrack ())
    (defun turn-on-pdbtrack ())
    (provide 'python)
    (provide 'python-21)
    )

After all this effort, I got fed up and gave up.
I'm going to just stick with built-in python.el and hope that someone
figures out a way to merge the two modes.


On 14 October 2012 08:25, David Engster <deng@...> wrote:

> 'daimrod' writes:
> > David Engster <deng@...> writes:
> >> This little Python issue has haunted us for years. I've now started a
> >> thread on Emacs-devel which hopefully will settle this issue once and
> >> for all. The Python situation on Emacs is really... complicated.
> >>
> >> -David
> >
> > Thank you for your attention, I'll follow the thread.
>
> I've now pushed a change that uses python-shell-internal-send-string. I
> have no idea whether that also works for the external
> python-mode. However, I'm not fond of supporting two different python
> modes in the first place. The Python support in CEDET is lacking anyway,
> so I'd rather not make it more complicated.
>
> We can apply small changes if necessary (for example regarding the
> initial require statement), but otherwise python-mode should provide the
> necessary aliases, or advice CEDET functions as necessary.
>
> -David
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

2012/10/14 Richard Kim <emacs18@...>:
> I wish I had the time to merge the two python modes into one so that we
> all use a single python mode rather than two.  I never seem to be able
> to find that time.  Below I provide my past efforts to support both in
> my environment and explain why I just gave up.
>
> First I created a boolean flag to switch between the two:
>
>   (defvar kimr-use-python-mode nil
>     "If non-nil, then enable the use of python-mode.el from python.org.
>   Default is nil which means to use the built-in python.el.")
>

I went exactly the same route, but then I decided to rewrite python.el
and that's what's on Emacs' trunk. The mode itself is not one or the
other, but got into the status of containing the most relevant
features of both. Not only that, currently PSF's python-mode.el is
borrowing stuff from this new mode. So chances are you are pretty much
covered in features and stability (very low number of outstanding bugs
as of today) and therefore you shouldn't lose time merging them IMHO.



Regards,
Fabián E. Gallina

>>>>> "D" == Daimrod  <daimrod@...> writes:

    D> Hi,
    D> I'm using the latest emacs (compiled from git) and I use python-mode
    D> (from bzr) instead of the built-in mode python.el.

    D> I've encountered this bug[1], however, `python-proc' is now deprecated
    D> and should be replaced by `python-shell-internal-get-or-create-process'.
    D> And that's cool, because python-mode uses the same name.

    D> Could semantic use `python-shell-internal-get-or-create-process' instead
    D> of the old `python-proc'?

    D> It just need to be replaced in
    D> wisent/python.el::semantic-python-get-system-include-path

    D> [1]http://comments.gmane.org/gmane.emacs.cedet/5512

    D> ------------------------------------------------------------------------------
    D> Don't let slow site performance ruin your business. Deploy New Relic APM
    D> Deploy New Relic app performance management and know exactly
    D> what is happening inside your Ruby, Python, PHP, Java, and .NET app
    D> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
    D> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
    D> Cedet-devel mailing list
    D> Cedet-devel@...
    D> https://lists.sourceforge.net/lists/listinfo/cedet-devel

I also encountered this bug. I think there are too many branches of
python mode in emacs. It leads to chaoes for setting python
configuration in emacs. They should be renovated and integrated.

Best wishes,

Easior 
------ 
"It was the age of wisdom, it was the age of foolishness, it was the
epoch of belief, it was the epoch of incredulity, it was the season of
Light, it was the season of Darkness, it was the spring of hope, it
was the winter of despair, we had everything before us, we had nothing
before us, we were all going direct to heaven, we were all going
direct the other way - in short, the period was so far like the
present period, that some of its noisiest authorities insisted on its
being received, for good or for evil, in the superlative degree of
comparison only."

                               TALES OF TWO CITIES, by Charles Dickens

>>>>> "RK" == Richard Kim <emacs18@...> writes:

    RK> I wish I had the time to merge the two python modes into one so that we
    RK> all use a single python mode rather than two.? I never seem to be able
    RK> to find that time.? Below I provide my past efforts to support both in
    RK> my environment and explain why I just gave up.

    RK> First I created a boolean flag to switch between the two:

    RK> ? (defvar kimr-use-python-mode nil
    RK> ??? "If non-nil, then enable the use of python-mode.el from python.org.
    RK> ? Default is nil which means to use the built-in python.el.")

    RK> Second I created an ELPA package called python-mode consisting of a
    RK> few files:

    RK> ??? $ cd ~/elpa-kimr/python-mode
    RK> ??? $ ls -l
    RK> ??? total 284
    RK> ??? -rw-r--r-- 1 kimr kimr? 85097 Oct 10? 2011 doctest-mode.el
    RK> ??? -rw-r--r-- 1 kimr kimr??? 786 Oct 10? 2011 NEWS
    RK> ??? -rw-r--r-- 1 kimr kimr?? 1581 Oct 10? 2011 pycomplete.el
    RK> ??? -rw-r--r-- 1 kimr kimr?? 3274 Oct 10? 2011 pycomplete.py
    RK> ??? -rw-r--r-- 1 kimr kimr 169873 Apr 20 17:11 python-mode.el
    RK> ??? -rw-rw-r-- 1 kimr kimr?? 5148 Mar? 2? 2012 pyton-mode.texi
    RK> ??? -rw-r--r-- 1 kimr kimr??? 316 Oct 10? 2011 README
    RK> ??? drwxr-xr-x 3 kimr kimr?? 4096 Oct 10? 2011 website
    RK> ??? $

    RK> Also I created another package consisting of a few other python packages
    RK> that I downloaded:

    RK> ??? $ cd ~/elpa-kimr/python-utils/
    RK> ??? $ ls -l
    RK> ??? total 3436
    RK> ??? -rw-r--r-- 1 kimr kimr?? 20856 Oct 10? 2011 ipython.el
    RK> ??? -rw-r--r-- 1 kimr kimr 3421663 Oct 10? 2011 pylookup.db
    RK> ??? -rw-r--r-- 1 kimr kimr??? 9137 Oct 10? 2011 pylookup.el
    RK> ??? -rwxr-xr-x 1 kimr kimr??? 7282 Oct 10? 2011 pylookup.py
    RK> ??? -rw-r--r-- 1 kimr kimr?? 33613 Oct 10? 2011 pymacs.el
    RK> ??? -rw-r--r-- 1 kimr kimr??? 4083 Oct 10? 2011 python-pep8.el
    RK> ??? -rw-r--r-- 1 kimr kimr??? 4170 Oct 10? 2011 python-pylint.el

    RK> Third I use this flag to do things differently for the two modes.
    RK> For example I turn on python-mode and python-utils packages only if I'm
    RK> using python-mode.el:

    RK> ? (when kimr-use-python-mode
    RK> ??? (kimr-package-activate 'python-mode))

    RK> ? (when kimr-use-python-mode
    RK> ??? (kimr-package-activate 'python-utils))

    RK> kimr-package-activate is a thin wrapper which adds an item to
    RK> package-load-list then calls (package-initialize).
    RK> Some, if not all, of the files in python-utils above work only for
    RK> python-mode.el, but not for the built-in python.el.
    RK> That is why I turn on these only when I'm using python-mode.el.

    RK> Also you have to be very careful to prevent loading the built-in
    RK> python.el if you are using python-mode.el, because the two define many
    RK> functions with the same names, but which behave differently.
    RK> So I tried the following:

    RK> ? ;; Autoloading for python-mode does not work, because of conflict with
    RK> ;; built-in
    RK> ? ;; python.el.? Also something within emacs seems to have (require 'python) so
    RK> ? ;; that if 'python-mode is loaded first, then (require 'python) later on
    RK> ? ;; clobbers python-mode.
    RK> ? (when kimr-use-python-mode
    RK> ??? (require 'python-mode)
    RK> ??? (kimr-disable-built-in-python-mode))

    RK> ? (defun kimr-disable-built-in-python-mode ()
    RK> ??? "Call this to improve chances of lisp/progmodes/python.el not getting loaded
    RK> ? accidentally.? This should be called after loading python-mode.el."
    RK> ??? (defun jython-mode ())
    RK> ??? (defun python-after-info-look ())
    RK> ??? (defun python-backspace (arg))
    RK> ??? (defun python-beginning-of-block (&optional arg))
    RK> ??? (defun python-check (command))
    RK> ??? (defun python-describe-symbol (symbol))
    RK> ??? (defun python-electric-colon (arg))
    RK> ??? (defun python-end-of-block (&optional arg))
    RK> ??? (defun python-expand-template (name))
    RK> ??? (defun python-fill-paragraph (&optional justify))
    RK> ??? (defun python-find-function (name))
    RK> ??? (defun python-find-imports ())
    RK> ??? (defun python-guess-indent ())
    RK> ??? (defun python-indent-line ())
    RK> ??? (defun python-load-file (file-name))
    RK> ??? (defun python-mark-block ())
    RK> ??? (defun python-next-statement (&optional count))
    RK> ??? (defun python-pdbtrack-toggle-stack-tracking (arg))
    RK> ??? (defun python-previous-statement (&optional count))
    RK> ??? (defun python-send-buffer ())
    RK> ??? (defun python-send-defun ())
    RK> ??? (defun python-send-region (start end))
    RK> ??? (defun python-send-region-and-go (start end))
    RK> ??? (defun python-send-string (string))
    RK> ??? (defun python-set-proc ())
    RK> ??? (defun python-setup-brm ())
    RK> ??? (defun python-shell (&optional argprompt))
    RK> ??? (defun python-shift-left (start end &optional count))
    RK> ??? (defun python-shift-right (start end &optional count))
    RK> ??? (defun python-switch-to-python (eob-p))
    RK> ??? (defun python-toggle-shells (arg))
    RK> ??? (defun run-python (&optional cmd noshow new))
    RK> ??? (defun turn-off-pdbtrack ())
    RK> ??? (defun turn-on-pdbtrack ())
    RK> ??? (provide 'python)
    RK> ??? (provide 'python-21)
    RK> ??? )

    RK> After all this effort, I got fed up and gave up.
    RK> I'm going to just stick with built-in python.el and hope that someone
    RK> figures out a way to merge the two modes.

    RK> On 14 October 2012 08:25, David Engster <deng@...> wrote:

    RK> 'daimrod' writes:
    >>  David Engster <deng@...> writes:
    >>>  This little Python issue has haunted us for years. I've now started a
    >>>  thread on Emacs-devel which hopefully will settle this issue once and
    >>>  for all. The Python situation on Emacs is really... complicated.
    >>> 
    >>>  -David
    >> 
    >>  Thank you for your attention, I'll follow the thread.
   
    RK> I've now pushed a change that uses python-shell-internal-send-string. I
    RK> have no idea whether that also works for the external
    RK> python-mode. However, I'm not fond of supporting two different python
    RK> modes in the first place. The Python support in CEDET is lacking anyway,
    RK> so I'd rather not make it more complicated.
   
    RK> We can apply small changes if necessary (for example regarding the
    RK> initial require statement), but otherwise python-mode should provide the
    RK> necessary aliases, or advice CEDET functions as necessary.
   
    RK> -David
   
    RK> ------------------------------------------------------------------------------
    RK> Don't let slow site performance ruin your business. Deploy New Relic APM
    RK> Deploy New Relic app performance management and know exactly
    RK> what is happening inside your Ruby, Python, PHP, Java, and .NET app
    RK> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
    RK> http://p.sf.net/sfu/newrelic-dev2dev
    RK> _______________________________________________
    RK> Cedet-devel mailing list
    RK> Cedet-devel@...
    RK> https://lists.sourceforge.net/lists/listinfo/cedet-devel


    RK> ------------------------------------------------------------------------------
    RK> Don't let slow site performance ruin your business. Deploy New Relic APM
    RK> Deploy New Relic app performance management and know exactly
    RK> what is happening inside your Ruby, Python, PHP, Java, and .NET app
    RK> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
    RK> http://p.sf.net/sfu/newrelic-dev2dev

    RK> _______________________________________________
    RK> Cedet-devel mailing list
    RK> Cedet-devel@...
    RK> https://lists.sourceforge.net/lists/listinfo/cedet-devel

It sounds a good idea.

Best wishes,

Easior 
------ 
"It was the age of wisdom, it was the age of foolishness, it was the
epoch of belief, it was the epoch of incredulity, it was the season of
Light, it was the season of Darkness, it was the spring of hope, it
was the winter of despair, we had everything before us, we had nothing
before us, we were all going direct to heaven, we were all going
direct the other way - in short, the period was so far like the
present period, that some of its noisiest authorities insisted on its
being received, for good or for evil, in the superlative degree of
comparison only."

                               TALES OF TWO CITIES, by Charles Dickens