Re: [Python-mode] one more myrkwid bug
Am 16.04.2011 13:01, schrieb Georg Brandl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.04.2011 23:41, schrieb Andreas Röhler: 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. FWIW, I would have no idea at all what py-indent-honor-listing does if I just saw the name. Georg what about `py-indent-honor-multiline-listing' ? Cheers Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] one more myrkwid bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.04.2011 09:42, schrieb Andreas Röhler: Am 16.04.2011 13:01, schrieb Georg Brandl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.04.2011 23:41, schrieb Andreas Röhler: 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. FWIW, I would have no idea at all what py-indent-honor-listing does if I just saw the name. Georg what about `py-indent-honor-multiline-listing' ? I think the listing is the strange word here. For me, a listing is a snippet of code printed in a book. Georg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2poQYACgkQN9GcIYhpnLDchACfQ/UvFKHyR87MVovONm3n/e3d V6AAnR+h4X8iYYp6e7ATWNt7Tmg7JoQ0 =n/q/ -END 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
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
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] one more myrkwid bug
On 4/14/2011 5:18 PM, Andreas Röhler wrote: Further fixes still ahead will take a little bit longer probably. Maybe we should keep the trunk for some days before a release, to get some more testers. I can spend a little time this weekend testing. what do I grab? ___ 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 14, 2011, at 07:59 PM, Eric S. Johansson wrote: On 4/14/2011 5:18 PM, Andreas Röhler wrote: Further fixes still ahead will take a little bit longer probably. Maybe we should keep the trunk for some days before a release, to get som e more testers. I can spend a little time this weekend testing. what do I grab? Andreas's branch can be had with: $ bzr branch lp:~a-roehler/python-mode/myrkwid -Barry signature.asc Description: PGP signature ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
