[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