Comment 4 for bug 1375122

On Sep 30, 2014, at 08:51 AM, Andreas Röhler wrote:

>On 29.09.2014 23:02, Jonathan C. Dodd wrote:
>> Unfortunately, C-j is only possible from the previous line, and I tend
>> to jump around the code quite a bit. When I come back wanting to e. g.
>> insert a new line into a matrix, I have to either go to the line before
>> the one I have inserted and press C-j from there, or press TAB
>> repeatedly and align the remainder with spaces. This is completely
>> unintuitive and inconsistent relative to other modes (c++-mode, js-mode,
>> emacs-lisp-mode etc etc, which all move cursor to rightmost sane
>> indentation when pressing TAB).
>
>Seeing you point. However, the way it behaves now is the default for years.
>
>May change the behaviour so jumps to outmost with first TAB, stepping
>backwards afterwards.

So let me see if I have this right. Take the following code example:

-----snip snip-----
def foo():
    call_something(a, b,
                   c, d,
                   e, f)
-----snip snip-----

If I put cursor at column 0 on the 'c, d,' line and hit C-o to open a new
line, then I hit TAB, cursor first goes to column 4. It takes 4 more hits of
TAB to align cursor under the 'a' argument of the previous line, i.e. column
19.

The proposal then is that the first TAB would align cursor to column 19, and
then the normal cycle would continue. I.e. second TAB would go to column 0,
then 4, 8, 12, 16, 19.

If I'm right about that, then +0 for this change. It's kind of always bugged
me too. :)

This also makes the behavior more consistent with what happens when you hit
py-newline-and-indent at the end of the 'a, b' line, where it opens the new
line and immediately puts cursor on column 19.

I give this only a +0 because there may be situations where this isn't useful
behavior, but I can't think of one right now. My suggestion would be to make
the change for now without an option. I and others can test it out it out of
the bzr repo and see if there are any hidden pain points.

Cheers,
-Barry