Repository navigation
Remove patterns for decreasing next indent level - #212
Conversation
|
... no discussion? |
|
Sorry, this was more of a temporary fix. I'm open to discussion, I just wanted to revert it back to where we originally were so that it wouldn't seem like there was any time pressure. |
|
Ok, well as you can imagine I'm a -1 on this. Both versions give you incorrect indentation, the difference is the old-old version (that this reverts to) is incorrect on every end-of-block-like statements (i.e. |
|
Yeah. However, and maybe this is personal taste, I feel that having the indentation consistently not change is somewhat more expected than having the indentation unexpectedly change. For the former I can get used to shift-tabbing after every end statement, whereas for the latter there's more muscle memory involved, as well as some cursor movement (as shift-tab will work anywhere, but tabbing will only work at the beginning of the line). |
|
No mouse touching needed - if you have at least one character highlighted tab will work as expected, so I trained a |
|
Did the tests run on this PR? I ran tests locally against master branch and had some failures. I had to update the spec file as seen in 7f8ea3b |
|
See my review comment in #214 - I'm not sure why but |
This pattern was recently removed from language-python. See atom/language-python#212 This commit handles that scenario, as well as fixes tests surrounding it. Other tests were adjusted to handle Atom not auto-inserting the indentation for several scenarios where we are currently using the `makeNewline` function. The tabs to indent (which are always a multiple of the editor's tab length) can be passed. This only happens on Atom > 1.23. There is probably a better solution for this in the long term.
This pattern was recently removed from language-python. See atom/language-python#212 This commit handles that scenario, as well as fixes tests surrounding it. Other tests were adjusted to handle Atom not auto-inserting the indentation for several scenarios where we are currently using the `makeNewline` function. The tabs to indent (which are always a multiple of the editor's tab length) can be passed. This only happens on Atom > 1.23. There is probably a better solution for this in the long term.
This pattern was recently removed from language-python. See atom/language-python#212 This commit handles that scenario, as well as fixes tests surrounding it. Other tests were adjusted to handle Atom not auto-inserting the indentation for several scenarios where we are currently using the `makeNewline` function. The tabs to indent (which are always a multiple of the editor's tab length) can be passed. This only happens on Atom > 1.23. There is probably a better solution for this in the long term.
This PR reverts the functional changes of #204. Unfortunately, there is no way (yet) to tell if we're in an
ifblock, which can lead to multiple dedenting in the following scenario:I would argue that that is worse than having to shift-tab after a return that is not in an if statement.
/cc @kbrose
Fixes #209