Re: [Python-mode] one more myrkwid bug
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. When the open paren ends a line, subsequent lines should get indented only one level, not to the space after an open paren. 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- 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? 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 signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
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
Re: [Python-mode] one more myrkwid bug
On Apr 15, 2011, at 10:01 PM, Andreas Röhler wrote: checked in the fix meanwhile. Behavior of trunk now default again. I just grabbed the update and it looks good. Thanks, I'll use this version over the weekend. As for the new variable, would prefer a pure boolean for simplicity. Maybe `py-indent-honor-listing' docstring already tells what's in question? So would t or nil give the default behavior? -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
On Apr 15, 2011, at 10:28 PM, Andreas Röhler wrote: Am 15.04.2011 22:09, schrieb Barry Warsaw: On Apr 15, 2011, at 10:01 PM, Andreas Röhler wrote: checked in the fix meanwhile. Behavior of trunk now default again. I just grabbed the update and it looks good. Thanks, I'll use this version over the weekend. As for the new variable, would prefer a pure boolean for simplicity. Maybe `py-indent-honor-listing' docstring already tells what's in question? So would t or nil give the default behavior? Nil - it's negligent now, doesn't care for listing... How about then, calling it py-indent-honor-open-paren? nil would still mean default behavior. -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] Control-L's break myrkwid
Oh you're going to love this one Andreas. ;) -snip snip- class Foo: def baz(self): ^L -snip snip- I'm not sure this will come through on the email, but there is a control-L in column zero of the last line. Now put point the line after `def baz` and hit TAB. You'll get a max-lisp-eval-depth error. Remove the ^L and it works fine. Note that Python treats ^L's as whitespace. Cheers, -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
Am 15.04.2011 22:24, schrieb Barry Warsaw: On Apr 15, 2011, at 10:28 PM, Andreas Röhler wrote: Am 15.04.2011 22:09, schrieb Barry Warsaw: On Apr 15, 2011, at 10:01 PM, Andreas Röhler wrote: checked in the fix meanwhile. Behavior of trunk now default again. I just grabbed the update and it looks good. Thanks, I'll use this version over the weekend. As for the new variable, would prefer a pure boolean for simplicity. Maybe `py-indent-honor-listing' docstring already tells what's in question? So would t or nil give the default behavior? Nil - it's negligent now, doesn't care for listing... How about then, calling it py-indent-honor-open-paren? Also good. But let's reflect maybe a little further: point for me is not just the open paren, but the multiline-form it introduces. Open paren followed by a closing same line are not of interest here. Therefore the `listing', which doesn't express that sufficiently either. Cheers Andreas nil would still mean default behavior. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Control-L's break myrkwid
Am 15.04.2011 23:20, schrieb Barry Warsaw: Oh you're going to love this one Andreas. ;) -snip snip- class Foo: def baz(self): ^L -snip snip- I'm not sure this will come through on the email, but there is a control-L in column zero of the last line. Now put point the line after `def baz` and hit TAB. You'll get a max-lisp-eval-depth error. Remove the ^L and it works fine. Note that Python treats ^L's as whitespace. Cheers, -Barry Hi, there is a phenomena I already experienced occassionaly, but couldn't track the cause: max-lisp-eval-depth error is caused by py-compute-indentation AFAIS. Now, when run it under edebug all goes through. Result is 8, correct. Afterwards also with normal exec error is gone. Will look into tomorrow further. Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode