From barry at python.org  Tue Oct  2 17:33:44 2007
From: barry at python.org (Barry Warsaw)
Date: Tue, 2 Oct 2007 11:33:44 -0400
Subject: [Python-mode] [Python-3000] Emacs22 python.el support for py3k
In-Reply-To: <766a29bd0710020828y150cfb5dgf33b440b02a71458@mail.gmail.com>
References: <766a29bd0710020737q4d4d762coa91b4c6bd15b278f@mail.gmail.com>
	<ca471dc20710020804k315b536dqfc3eec392c05a0b6@mail.gmail.com>
	<766a29bd0710020828y150cfb5dgf33b440b02a71458@mail.gmail.com>
Message-ID: <8B5D00B9-F765-43F6-B3DE-AA6BB50CA611@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 2, 2007, at 11:28 AM, Adam Hupp wrote:

> On 10/2/07, Guido van Rossum <guido at python.org> wrote:
>>
>> Just curious -- how do python.el and python-mode.el differ?
>
> Off the top of my head:
>
>  * python-mode.el did not play well with transient-mark-mode
> (mark-block didn't work).   transient-mark-mode highlights the marked
> region and is required for other functions (e.g. comment-dwim).
>
>  * python-mode.el had problems with syntax highlighting in the
> presence of triple quoted strings and in comments.  python.el does
> not.
>
>  * python.el is supposed to be more consistent with other major modes.
>  e.g. M-; for comment.
>
>  * python.el ships with emacs.  There are claims that python-mode.el
> was not as well maintained for FSF emacs as XEmacs.

It would be nice if there were only one mode that worked with both  
FSF Emacs and XEmacs and merged the best qualities of both modes.  I  
don't have much time to work on that, and I suspect Skip is pretty  
busy too.  Adam, if you're interested, willing, and able to help  
develop such a merge, python-mode at python.org would be the place to do  
so.

I'd certainly be willing to test and I'd try to do a limited amount  
of XEmacs compatibility hacking.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRwJk2XEjvBPtnXfVAQJ9ZgP/bbG+OSHEnWGCBIXibnTzxEUL2ifIO8YU
E/odKLMogXKFc40/weansKpjX9+Mv+/ye7a49HPH+AZ2vxKJsFvZVHill6F3pbh2
bd+94O1AkYIsuJwO7u3Pc3clje85jXDSUtmPRM3yWGweLDNNDaS4kxE02tNqdSTd
rKiHn4gUzYk=
=zMKd
-----END PGP SIGNATURE-----

From noreply at sourceforge.net  Wed Oct 17 21:57:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 17 Oct 2007 12:57:11 -0700
Subject: [Python-mode] [ python-mode-Patches-1815323 ] more flexible
	indentation of continued lists/tuples/dicts
Message-ID: <E1IiF0x-0001c6-4t@sc8-sf-web23.sourceforge.net>

Patches item #1815323, was opened at 2007-10-17 15:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1815323&group_id=86916

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: A. MacLeod (allistermacleod)
Assigned to: Nobody/Anonymous (nobody)
Summary: more flexible indentation of continued lists/tuples/dicts

Initial Comment:
I wanted to be able to indent a continued tuple more than one column when the beginning of the tuple is just sitting on the line by itself:

(long, sequence, of_items,
    that, needs, to_be, wrapped) = input_list

^^^^ - I'd like to have it indent four spaces, rather than just one, but only in this case.. if it's not the first thing, I want normal behavior:

packed_entry = (long, sequence, of_items,
                that, needs, to_be, wrapped)

               ^^
In these cases the continuation lines up with the open parenthesis (or bracket or brace in the case of lists and dicts, respectively).

Thus, this patch, which introduces the custom variable py-indent-continuations-further (boolean).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=581351&aid=1815323&group_id=86916