unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dave Love <fx@gnu.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Christoph <cschol2112@googlemail.com>,
	Chong Yidong <cyd@stupidchicken.com>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Current state of python.el in the Emacs trunk
Date: Mon, 21 Feb 2011 00:48:39 +0000	[thread overview]
Message-ID: <87r5b2kyag.fsf@liv.ac.uk> (raw)
In-Reply-To: jwvsjvpueb8.fsf-monnier+emacs@gnu.org

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The only problem is that the very
> reason for desiring such a switch is because nobody (including and
> especially the most obvious candidate, Dave) has been willing to
> maintain our python.el.

I wasn't unwilling to maintain it, and I attempted in the past to get
the Emacs version fixed and prevent problems being introduced, but that
was rather unrewarding, and I gave up.  It's not appropriate anyway, as
rms seems to think I act in bad faith these days.  If I was mainatinaing
it, I'd just do what I've been doing separately, which doesn't seem
acceptable.  I haven't checked exactly what's currently in Emacs, but
I'm baffled why, for instance, it got three .py files instead of a more
maintainable one, and why changes were made which clearly broke things.

> Now Fabian proposes a third Python mode.  That sounds like adding innnsult
> to injury, but I must say it is very tempting:
> - its copyright is clean, like our python.el.
> - he seems interested in maintaining it.

I don't know what that's about, but I maintain a version with no unfixed
bugs I'm aware of, and had various features (and not misfeatures) the
others don't.  Until I started working on it at the university, it was
covered by an assignment (given potential problems with my previous
employment were disregarded) and could just have been used.  It may well
need to be fixed for the incompatible Emacs changes that get made, but
I'd fix it if told, and if it didn't break it for released versions.

> Of course, I'd rather work at bringing the various python modes closer
> to each other, rather than have them fork even further, so I'm not sure
> what's the best course here.

Why?  python.el was intentionally different from python-mode.el for
various reasons, like being a well-behaved Emacs (as opposed to XEmacs?)
mode.  I don't understand why you'd want something whose distinction as
far as I can tell is violating conventions with fewer features and extra
bugs.  Actually, after all the propaganda about it, python.el code now
seems to be migrating into python-mode.el (after stripping the copyright
headers, contrary to the licence, of course).

I do find this all pretty sad.



  parent reply	other threads:[~2011-02-21  0:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-27  4:32 Current state of python.el in the Emacs trunk Christoph
2011-01-27 18:35 ` Stefan Monnier
2011-01-28  0:23   ` Christoph
2011-02-15 20:07   ` Dave Love
2011-02-15 20:13     ` Chong Yidong
2011-02-15 22:33       ` Stefan Monnier
2011-02-16  3:05         ` Christoph
2011-02-16  4:32           ` Stefan Monnier
2011-02-21  0:49             ` Dave Love
2011-02-16  7:07           ` Fabian Ezequiel Gallina
2011-02-21  0:52             ` Dave Love
2011-02-21  0:51           ` Dave Love
2011-02-24  6:13             ` Christoph
2011-03-29  4:58               ` ken manheimer
2011-03-29 14:03                 ` Stefan Monnier
2011-03-29 15:34                   ` Fabian Ezequiel Gallina
2011-03-30  2:12                   ` Christoph Scholtes
2011-02-21  0:48         ` Dave Love [this message]
2011-02-21  2:10           ` Stephen J. Turnbull
2011-02-21  2:25           ` Stephen J. Turnbull
2011-02-21 22:25           ` Stefan Monnier
2011-02-21  0:48       ` Dave Love
  -- strict thread matches above, loose matches on Subject: below --
2011-01-27  9:33 Андрей Парамонов

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r5b2kyag.fsf@liv.ac.uk \
    --to=fx@gnu.org \
    --cc=cschol2112@googlemail.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).