py-indent-line behavior from 6.1.1

[Jonathan C. Dodd]

Consider this sequence of actions:

1. Type "if sum(0, 1,"
2. M-x newline
3. TAB

Upon hitting TAB, version 6.1.1 and older first placed cursor to the outermost indentation and then cycled through other possible indentations (0 and above in steps of 4). Versions 6.1.2 and 6.1.3 omit the correct indentation guess and start cycling immediately.

I have looked through changelogs of the two newer versions and found no explicitly stated motivation for changing the behavior. Is it possible to return the old one?

[Andreas Roehler (a-roehler)]

On 29.09.2014 07:49, Jonathan C. Dodd wrote:
> Public bug reported:
>
> Consider this sequence of actions:
>
> 1. Type "if sum(0, 1,"
> 2. M-x newline
> 3. TAB
>
> Upon hitting TAB, version 6.1.1 and older first placed cursor to the
> outermost indentation and then cycled through other possible
> indentations (0 and above in steps of 4). Versions 6.1.2 and 6.1.3 omit
> the correct indentation guess and start cycling immediately.
>
> I have looked through changelogs of the two newer versions and found no
> explicitly stated motivation for changing the behavior. Is it possible
> to return the old one?
>

The workflow here would be to call newline-and-indent, commonly C-j

With TAB python-mode increments one step until outmost indent.
 From outmost first TAB does nothing - thus reminding user pos is outmost already.
A second TAB would jump to col 0.

 From outmost stepping down one level <backspace> seems convenient.

[Jonathan C. Dodd (jc-dodd)]

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). Pressing C-j on the line I want to indent produces a newline and lots of spaces on the line after the inserted one.

[Andreas Roehler (a-roehler)]

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.

Or have another boolean and customization?
Barry, WDYT?

Will cc it to python-mode mailing-list.

[Barry Warsaw (barry)]

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

[Andreas Roehler (a-roehler)]

On 30.09.2014 16:48, Barry Warsaw wrote:
> 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
>

Okay, will look for this when upcoming release 6.1.4 is done.

Andreas