Am 15.04.2011 13:49, schrieb Barry Warsaw:
Hi Andreas,
On Apr 15, 2011, at 08:59 AM, Andreas Röhler wrote:
def foo():
x = dict(
a=1,
b=2,
c=3,
)
which looks okay for me.
Except it's a regression from the trunk.
Hi Barry,
that might be. Admittingly worked the opposite direction.
When the open paren ends a line,
subsequent lines should get indented only one level, not to the space after an
open paren.
My understanding here was: when a listing --list, tupel, dict-- starts,
line-breaks doesn't matter semantically, so attention should be laid
onto the colum of list-starter.
If you indent just the offset of former line, the column than indicates
nothing specific, it's a purely graphical indent.
So far at least my conclusion from bug #328842 - more flexible
indentation of continued lists/tuples/dicts
Seems headed into something wrong :(
At least, that's the way it should work by default.
If "4 spaces after assignement start" shall be the rule, we get next bug
report, should someone leave out the spaces, which would produce a nasty
def foo():
x=dict(
a=1,
b=2,
c=3,
)
Note that it doesn't have anything to do with the assignment, or the dict.
It's the open paren ending a line that's the critical thing here. Here's
another example. This is what myrkwid gives you:
-----snip snip-----
def foo():
do_something_first(
a=1,
b=2,
c=3,
)
-----snip snip-----
But this is what trunk gives you:
-----snip snip-----
def foo():
do_something_first(
a=1,
b=2,
c=3,
)
-----snip snip-----
Well, if we have just these both cases, we can use a boolean.
A further problem with myrkwid is that if I'm typing the first few lines:
-----snip snip-----
def foo():
do_something_first(
a=1,
-----snip snip-----
and now I realize that 'a=1' is indented too far to the right, so I manually
correct it to start under the 'o' in 'something'. Then I go to the end of the
line and hit return. I end up with this, which is definitely not correct:
-----snip snip-----
def foo():
do_something_first(
a=1,
b=2,
-----snip snip-----
'b' should line up under 'a'.
See what I mean?
Yeah, second indent is right, first wrong :)
OK, going to re-install the trunks behavior at least as an option/default.
What about `py-indent-honor-listing' - which would be `nil' meeting your
preferences?
Cheers
Andreas
Would make that customizable with a var
align-to-dict
or so, which would be true here, nil the default. (?)
BTW: indent should go along with meaning, if possible.
Well, you being the authority :)
Or just the most adventurous and vocal, anyway :). Indentation controlling
variables should be well-named and discoverable, but you just have to be
careful to capture the right semantics. In this case, the indentation has
nothing to do with assignments or dicts, but everything to do with lines that
end in open parens.
Hope that helps!
PS Applied patch from 691542 this morning. Will push it into myrkwid also.
Awesome, thanks!
-Barry
_______________________________________________
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
