[Python-mode] one more myrkwid bug
Andreas Röhler
andreas.roehler at online.de
Fri Apr 15 17:05:22 CEST 2011
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
More information about the Python-mode
mailing list