Pymacs on GitHub (fwd)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Pymacs on GitHub (fwd)

Skip Montanaro-3

Thought python-mode folks might find this announcement at least peripherally
interesting since it involves Python/Emacs integration.

Skip



Hi, people.

This quick hello to say I pushed the Pymacs repository to GitHub.  See
http://github.com/pinard/Pymacs

I would like to experiment with these facilities for a while.  There is
an issue tracker and a wiki, and I wonder if we should use them.  If
not, better deactivate their tabs early, so people do not get tempted to
rely on them.

The advantages of such maintainer toys are well known, there is
presumably no need to repeat them.  But I have a few cons, that I'd like
to explicit a bit here, seeking for opinions or advice.

All issues and wiki pages should ideally be bulk-copyable elsewhere,
would the inclination arise.  I would not like feeling tied to GitHub,
the same I once felt tied to Sourceforge.  Git gives us the freedom of
having usable clones of Pymacs sources outside GitHub, and the GitHub
copy is just a clone among others.  I would ideally seek the same
freedom for other services.

Hopefully, issues and wiki pages keep history.  Another point is
protection, if any, against spam.  I had a Wiki, not so long ago, that I
ended up deactivating, as I find neither pleasure nor time, really,
playing games with defacers.

If the issue is attractive enough (it surely looks simple), I might be
tempted to upload a few pending issues to it, and I wonder if and how I
should mask email addresses of submitters, or otherwise, and how to
establish some kind of links so I could retrieve the original
information if needed.  My intuition tells me it works more nicely for
submitters already having a GitHub account, but I do not know yet.  I
have a strong point against issue trackers in that maintainers should
never force them upon users, but this implies that maintainers could be
able to easily manage issues coming from other means — email being the
most common.

GitHub wiki, well, that's yet another markup language to learn.  It's a
bit sad each wiki has its own.  Also, I much enjoy the ease by which
Tomboy allows me to maintain a lot of notes, a few of them for Pymacs.
It would be fun for me to have some form of inter-operability between
Wiki pages and Tomboy notes — I wonder how easy it would be for me to
organize.

A final point would be to document the GitHub facilities we choose to
retain for use in the current Pymacs sites, and cross-link everything
appropriately, so the whole stays nice, usable and elegant enough.

--
François Pinard   http://pinard.progiciels-bpi.ca


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Pymacs devel" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/pymacs-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Pymacs on GitHub (fwd)

Andreas Röhler-2


Hi Skip,

thats interesting indeed.

Setting up an appropriate state-of-the-art
(X)Emacs python-environement is an issue requested again and
again by users but not delivered until yet.

What about to include these and some other useful
stuff into XEmacs python-modes?

Then provide an installer, to that Python-Folks must
not learn Emacs-Lisp first?

Shouldn't the XEmacs packages system deliver the needed
utils for such a task?

Andreas

--
https://code.launchpad.net/s-x-emacs-werkstatt/
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/






[hidden email] wrote:

> Thought python-mode folks might find this announcement at least peripherally
> interesting since it involves Python/Emacs integration.
>
> Skip
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Pymacs on GitHub
> From:
> François Pinard <[hidden email]>
> Date:
> Mon, 28 Sep 2009 08:07:59 -0400
> To:
> Pymacs people <[hidden email]>
>
> To:
> Pymacs people <[hidden email]>
>
...

> Hi, people.
>
> This quick hello to say I pushed the Pymacs repository to GitHub.  See
> http://github.com/pinard/Pymacs
>
> I would like to experiment with these facilities for a while.  There is
> an issue tracker and a wiki, and I wonder if we should use them.  If
> not, better deactivate their tabs early, so people do not get tempted to
> rely on them.
>
> The advantages of such maintainer toys are well known, there is
> presumably no need to repeat them.  But I have a few cons, that I'd like
> to explicit a bit here, seeking for opinions or advice.
>
> All issues and wiki pages should ideally be bulk-copyable elsewhere,
> would the inclination arise.  I would not like feeling tied to GitHub,
> the same I once felt tied to Sourceforge.  Git gives us the freedom of
> having usable clones of Pymacs sources outside GitHub, and the GitHub
> copy is just a clone among others.  I would ideally seek the same
> freedom for other services.
>
> Hopefully, issues and wiki pages keep history.  Another point is
> protection, if any, against spam.  I had a Wiki, not so long ago, that I
> ended up deactivating, as I find neither pleasure nor time, really,
> playing games with defacers.
>
> If the issue is attractive enough (it surely looks simple), I might be
> tempted to upload a few pending issues to it, and I wonder if and how I
> should mask email addresses of submitters, or otherwise, and how to
> establish some kind of links so I could retrieve the original
> information if needed.  My intuition tells me it works more nicely for
> submitters already having a GitHub account, but I do not know yet.  I
> have a strong point against issue trackers in that maintainers should
> never force them upon users, but this implies that maintainers could be
> able to easily manage issues coming from other means — email being the
> most common.
>
> GitHub wiki, well, that's yet another markup language to learn.  It's a
> bit sad each wiki has its own.  Also, I much enjoy the ease by which
> Tomboy allows me to maintain a lot of notes, a few of them for Pymacs.
> It would be fun for me to have some form of inter-operability between
> Wiki pages and Tomboy notes — I wonder how easy it would be for me to
> organize.
>
> A final point would be to document the GitHub facilities we choose to
> retain for use in the current Pymacs sites, and cross-link everything
> appropriately, so the whole stays nice, usable and elegant enough.
>
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Pymacs on GitHub (fwd)

Skip Montanaro-3

    Andreas> What about to include these and some other useful stuff into
    Andreas> XEmacs python-modes?

What about rewriting python-mode using Pymacs?

Sorry, I don't know how to answer your other questions.

Skip
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Pymacs on GitHub (fwd)

Barry Warsaw
I'm not a fan of git, especially when there are two viable Python-
based DVCS's (and I'm biased about which one of those I prefer of  
course :).

On Sep 29, 2009, at 1:29 PM, [hidden email] wrote:

>
>    Andreas> What about to include these and some other useful stuff  
> into
>    Andreas> XEmacs python-modes?
>
> What about rewriting python-mode using Pymacs?

I would not be in favor of that.  While I think Pymacs is very cool  
stuff, I view python-mode.el as lower-level, and it should remain pure  
elisp, at least to handle the basics of editing Python code.  It would  
be interesting to explore add-ons and extensions though that take  
advantage of Pymacs for more advanced, IDE-like stuff.  Let's keep  
python-mode.el itself simple though.

-Barry


_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

PGP.sig (849 bytes) Download Attachment