* plan for emacs python tooling (esp python.el, python-mode.el)?
@ 2010-03-15 16:47 Tom Roche
2010-03-16 3:58 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Tom Roche @ 2010-03-15 16:47 UTC (permalink / raw)
To: emacs-devel
summary: Is the near-term plan for GNU emacs (e.g. for 2010-2011) to
ship with python.el, python-mode.el, both, or something completely
different?
details:
Please note I am not seeking to send or receive flame regarding the
various tools, only to get something like "the opinion of the emacs
developers": will emacs in the near future (i.e. 2010-2011) provide
python.el, python-mode.el, both, or something completely different?
I am a long-time (though not expert) GNU Emacs user who has started to
code python more intensively, and would therefore prefer an optimal
python development environment for emacs. Unfortunately there appears to
be no PDEE à la the JDEE, and not even a consensus mode (as was
cperl-mode when I coded perl ~y2k). Thus I need to decide whether to
base my emacs configuration efforts on python.el or python-mode.el.
(Preferably not both, given limited emacs configuration time.)
I would prefer emacs python tooling that
* integrates most easily with other emacs metatools (e.g. CEDET)
* ships by default with GNU emacs.
(and would like for those sets to be identical :-) I would therefore
like to know what is/are
* the preferences among {GNU emacs users, python developers}
* the plans of the emacs development community (to the extent they are
unitary)
regarding emacs python tooling.
I sought to determine this myself via some research (which could be
wrong--your comments and corrections are appreciated) over the weekend,
but found neither explicit plan(s) regarding, nor consensus on the
merits of, python.el vs python-mode.el. What I (apparently) found is:
0 Currently python.el is distributed with emacs releases, python-mode.el
is distributed with python releases.
1 python.el remains alone in the current emacs sources:
https://savannah.gnu.org/projects/emacs
> you can browse the source repository or access it via bzr with
> bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk
me@it:~$ sudo aptitude install bzr
me@it:~$ D=/tmp/emacs-bzr ; mkdir -p $D ; pushd $D
me@it:/tmp/emacs-bzr$ date ; bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk
> Mon Mar 15 10:45:07 EDT 2010
...
> Branched 99665 revision(s).
me@it:/tmp/emacs-bzr$ date ; find -type f | fgrep -ie 'python'
> Mon Mar 15 11:35:11 EDT 2010
> ./trunk/lisp/cedet/semantic/wisent/python.el
> ./trunk/lisp/cedet/semantic/wisent/python-wy.el
> ./trunk/lisp/progmodes/python.el
me@it:/tmp/emacs-bzr$ head trunk/lisp/cedet/semantic/wisent/python-wy.el
> ;;; semantic/wisent/python-wy.el --- Generated parser support file
...
me@it:/tmp/emacs-bzr$ diff -u trunk/lisp/cedet/semantic/wisent/python.el trunk/lisp/progmodes/python.el
...
-;; Parser support for Python.
+;; Major mode for editing Python, with support for inferior processes.
...
2 There was a long discussion on emacs-devel last year (Jan-Feb 2009)
regarding switching from python.el to python-mode.el, but there was
apparently neither definitive conclusion nor subsequent discussion.
3 Stefan Monnier (one of the main emacs maintainers) has expressed a
conditional preference for python-mode.el:
http://lists.gnu.org/archive/html/emacs-devel/2009-02/msg00113.html
> all the Python coders I know install python-mode.el rather than use
> python.el. I don't know if it's representative, but if that's the
> case, then our users would be better served with python-mode.el
4 There has been much discussion on the python-mode list
http://mail.python.org/mailman/listinfo/python-mode
since Feb 2009 regarding the switch, but no announcements regarding
the underlying copyright assignment issues.
5 The python-mode.el development community seems to be larger and
better organized, or at least their maillist is public.
6 The python.el development community appears to be Dave Love. That
being said, python.el seems to have python 3 support already, which
python-mode.el seems to lack.
7 Web searches I have made <insert caveats here/> for various
combinations of terms={emacs, python, development} seems to show
some preference among GNU emacs users for using python.el, and for
basing integrations with other tools (e.g. CEDET) on python.el.
Feel free to reply off- or on-list, and to forward.
TIA, Tom Roche <Tom_Roche@pobox.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: plan for emacs python tooling (esp python.el, python-mode.el)?
2010-03-15 16:47 plan for emacs python tooling (esp python.el, python-mode.el)? Tom Roche
@ 2010-03-16 3:58 ` Stefan Monnier
2010-03-16 10:47 ` Andreas Roehler
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2010-03-16 3:58 UTC (permalink / raw)
To: emacs-devel; +Cc: Tom Roche
> summary: Is the near-term plan for GNU emacs (e.g. for 2010-2011) to
> ship with python.el, python-mode.el, both, or something completely
> different?
The plan is to ship it with python.el until we can ship it with
python-mode.el (the barrier being coipyright assignments).
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: plan for emacs python tooling (esp python.el, python-mode.el)?
2010-03-16 3:58 ` Stefan Monnier
@ 2010-03-16 10:47 ` Andreas Roehler
2010-03-16 11:37 ` Eric M. Ludlam
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Roehler @ 2010-03-16 10:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Tom Roche, python-mode, emacs-devel
Stefan Monnier wrote:
>> summary: Is the near-term plan for GNU emacs (e.g. for 2010-2011) to
>> ship with python.el, python-mode.el, both, or something completely
>> different?
>
> The plan is to ship it with python.el until we can ship it with
> python-mode.el (the barrier being coipyright assignments).
>
>
> Stefan
>
>
>
Hi Stefan,
as far as I understand the OP, the focus is rather the python-environment than the editor.
As far as it concerns editing, python.el, python-mode.el are both suitable IMHO.
Don't see a real gain by switching one for the other. If a precise feature is missed here or there, let's implement it...
Progress would mean having a download source for an environment, which offers all needed at once:
debugging, refactoring, auto-completion etc.
Such an environment should enable emacs editing modes, but vim and other free tools too.
Andreas
--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: plan for emacs python tooling (esp python.el, python-mode.el)?
2010-03-16 10:47 ` Andreas Roehler
@ 2010-03-16 11:37 ` Eric M. Ludlam
2010-03-16 14:43 ` Tom Roche
0 siblings, 1 reply; 5+ messages in thread
From: Eric M. Ludlam @ 2010-03-16 11:37 UTC (permalink / raw)
To: Andreas Roehler; +Cc: Tom Roche, Stefan Monnier, python-mode, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
On 03/16/2010 06:47 AM, Andreas Roehler wrote:
> as far as I understand the OP, the focus is rather the python-environment than the editor.
>
> As far as it concerns editing, python.el, python-mode.el are both suitable IMHO.
>
> Don't see a real gain by switching one for the other. If a precise feature is missed here or there, let's implement it...
>
> Progress would mean having a download source for an environment, which offers all needed at once:
> debugging, refactoring, auto-completion etc.
>
> Such an environment should enable emacs editing modes, but vim and other free tools too.
The CEDET support for python parsing (which would handle autocompletion
type tasks amonng others) is also (as far as I know) held up by a
copyright assignment.
Exuberent ctags supports python (though I don't know by how much), and
adding support in the CEDET/Semantic exuberant ctags support wouldn't be
too hard. Likely something like the patch attached.
Hmmm. I see that the exuberent ctags support does not appear to be a
part of Emacs. Well, you could try the most recently posted version of
CEDET with the below patch instead if you wanted to try it.
Eric
[-- Attachment #2: semantic-ectag-lang.el.patch --]
[-- Type: text/x-diff, Size: 1656 bytes --]
*** semantic-ectag-lang.el.~1.11.~ 2010-03-15 22:23:11.000000000 -0400
--- semantic-ectag-lang.el 2010-03-16 07:32:08.000000000 -0400
***************
*** 1,6 ****
;;; semantic-ectag-lang.el --- Exuberent Ctags per-language support
! ;; Copyright (C) 2008, 2009 Eric M. Ludlam
;; Author: Eric M. Ludlam <eric@siege-engine.com>
;; X-RCS: $Id: semantic-ectag-lang.el,v 1.11 2010/03/15 13:40:55 xscript Exp $
--- 1,6 ----
;;; semantic-ectag-lang.el --- Exuberent Ctags per-language support
! ;; Copyright (C) 2008, 2009, 2010 Eric M. Ludlam
;; Author: Eric M. Ludlam <eric@siege-engine.com>
;; X-RCS: $Id: semantic-ectag-lang.el,v 1.11 2010/03/15 13:40:55 xscript Exp $
***************
*** 63,68 ****
--- 63,69 ----
;(semantic-ectag-add-language-support lua-mode "lua" "f")
(semantic-ectag-add-language-support pascal-mode "pascal" "fp")
(semantic-ectag-add-language-support perl-mode "perl" "cflpsd")
+ (semantic-ectag-add-language-support python-mode "python" "cfmvi")
;(semantic-ectag-add-language-support rexx-mode "rexx" "s")
;(semantic-ectag-add-language-support sql-mode "sql" "s")
(semantic-ectag-add-language-support tcl-mode "tcl" "cmp")
***************
*** 96,101 ****
--- 97,103 ----
;;(add-hook 'lua-mode-hook 'semantic-ectag-simple-setup)
(add-hook 'pascal-mode-hook 'semantic-ectag-simple-setup)
(add-hook 'perl-mode-hook 'semantic-ectag-simple-setup)
+ (add-hook 'python-mode-hook 'semantic-ectag-simple-setup)
;;(add-hook 'rexx-mode-hook 'semantic-ectag-simple-setup)
(add-hook 'tcl-mode-hook 'semantic-ectag-simple-setup)
;;(add-hook 'vera-mode-hook 'semantic-ectag-simple-setup)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: plan for emacs python tooling (esp python.el, python-mode.el)?
2010-03-16 11:37 ` Eric M. Ludlam
@ 2010-03-16 14:43 ` Tom Roche
0 siblings, 0 replies; 5+ messages in thread
From: Tom Roche @ 2010-03-16 14:43 UTC (permalink / raw)
To: emacs-devel; +Cc: Dave Love, cedet-devel, python-mode
summary: I'll followup with the python*el folks and CEDET regarding
current and future python development environments for GNU emacs.
details:
Tom Roche Mon, Mar 15, 2010 at 11:47 AM
>>>> Is the near-term plan for GNU emacs (e.g. for 2010-2011) to ship
>>>> with python.el, python-mode.el, both, or something completely
>>>> different?
Stefan Monnier Mon, 15 Mar 2010 23:58:04 -0400
>>> The plan is to ship it with python.el until we can ship it with
>>> python-mode.el (the barrier being [copyright] assignments).
<sigh/> Given the duration of that barrier to date, ISTM one must
assume python-mode.el's copyrights won't be assigned.
Andreas Roehler Tue, 16 Mar 2010 11:47:57 +0100 (rearranged)
>> as far as I understand the OP, the focus is rather the python-
>> environment than the editor.
That is technically correct, but (I suspect, and ICBW) practically,
* the python development environment needs a platform.
* Given that coding python ~= editing test files, that platform is
most reasonably a text editor.
Hence I want a
>>>> PDEE à la the JDEE
http://jdee.sourceforge.net/
>>>>> A Java Development Environment for Emacs
...
>>>>> JDEE features include
...
>>>>> * syntax coloring
>>>>> * auto indentation
>>>>> * compile error to source links
>>>>> * source-level debugging
>>>>> * source code browsing
>>>>> * make file support
>>>>> * automatic code generation
IIUC this is the "best of breed" code environment for GNU emacs (am I
missing something?) so I regard it as a model.
>> Such an environment should enable emacs editing modes, but vim and
>> other free tools too.
Again, technically correct, but
* I want a python development environment for GNU emacs, since that's
what my fingers know. (Which is why I'm not (at least initially)
getting Wing or PyDev: I'd end up using emacs to edit the files
underneath, as I was forced to do when working on Eclipse.)
* The *macs ecosystem already contains robust tools for providing
coder services (e.g. the "JDEE features" above), e.g. CEDET. Since
the JDEE definitely exploits CEDET, and GNU emacs is apparently in
the process of integrating CEDET (no?), I tend to assume a PDEE
should do this too.
* I don't see the editor-independent interfaces to the services above.
Am I missing something? (I am very new to python.)
If the above is true, then it seems the fastpath to a richer PDEE is
CEDET integration. No? Except ...
Eric M. Ludlam Tue, 16 Mar 2010 07:37:13 -0400
> The CEDET support for python parsing (which would handle
> autocompletion type tasks [among] others) is also (as far as I know)
> held up by a copyright assignment.
<sigh/> I'll followup about that separately.
your assistance is appreciated, Tom Roche <Tom_Roche@pobox.com>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cedet-devel mailing list
Cedet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-03-16 14:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-15 16:47 plan for emacs python tooling (esp python.el, python-mode.el)? Tom Roche
2010-03-16 3:58 ` Stefan Monnier
2010-03-16 10:47 ` Andreas Roehler
2010-03-16 11:37 ` Eric M. Ludlam
2010-03-16 14:43 ` Tom Roche
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.