-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework indentation after assignment #42
Conversation
5f62689
to
37994ae
Compare
so triple quoted strings become
? IMO that is the right choice, just confirming |
This PR doesn't do that, but I have considered that and pushed the code for it to fe/continue-triple-strings some time ago. I was just getting at the similarity between |
So this will not allow me to break after averyverylongidentifier =
if averyverylongcondition && maybeanotherone
x
else
y
end is not allowed (if I manually break)? Would I then need to write averyverylongidentifier = \
if averyverylongcondition && maybeanotherone
x
else
y
end or averyverylongidentifier = if (
averyverylongcondition && maybeanotherone
)
x
else
y
end to achieve this? |
the extremely popular
if
|
Perhaps the line break could be left to the user. Runic doesn't really care about line breaks elsewhere. |
👍 And if linebreaks are kept, I think averyverylongidentifier =
if averyverylongcondition && maybeanotherone
x
else
y
end would be the simplest choice ("add 1 indentation level because the line is continued"). If the condition becomes long enough, x = if (
longcondition
)
yes
else
no
end form either. |
I don't want to indent the block depending on whether there is a preceeding newline or not. It would be
if there is a newline after the
if there is not. I don't think I have seen intended blocks like that in the wild. Same for
But for this I am more tempted to indent (compared to if/try blocks). |
This confuses me. Currently, Runic also does a =
-b
+ b
a =
b
and further a =
-if x; y else z end
+ if x; y else z end so why should the block form be special-cased? Isn't this just an instance of indenting continued lines like a = b +
-c
+ c ? |
I mean, perhaps newline after
Well, with this PR that would become
but I think perhaps blocks should be detangled into multiple lines like
|
This patch implements `# runic: on` and `# runic: off` toggle comments that can be included in the source to toggle formatting on/off. The two comments i) must be placed on their own lines, ii) must be on the same level in the expression tree, and iii) must come in pairs. An exception to condition iii) is made for top level toggle comments so that formatting for a whole file can be disabled by a `# runic: off` comment at the top without having to add one also at the end of the file. For compatibility with JuliaFormatter, `#! format: (on|off)` is also supported but it is not possible to pair e.g. a `# runic: off` comment with a `#! format: on` comment. Closes #12, closes #42.
I still don't understand what the problem would be with the a =
if x
y
else
z
end variant so much that Runic should start removing manual linebreaks for this. I find it perfectly legible and also consistent with the "continued lines add indentation" rule. But as I wrote elsewhere, that is fine. (Anyway, I can always just wrap the condition, or the whole expression, in parentheses.) |
This patch reworks the indentation after assignment. For "blocklike" (try/if/triple-strings) right hand sides the indentation is disabled. Closes #39.
37994ae
to
8cda024
Compare
After some great discussion on Slack it seems that the majority thinks that block constructs like I have updated the PR to do this, and also updated so that newlines between |
This patch reworks the indentation after assignment. For "blocklike" (try/if/triple strings) right hand sides the indentation is disabled. Superfluous newlines are removed. For example
will become
A valid alternative is
This highlights the start/end of the right hand side of the assignment in a better way, but it doesn't look very nice and this style is never really seen in the wild. For triple strings I think it is OK though, e.g.
vs the current (and seen more in the wild)
Closes #39.