This patch changes where spaces are inserted before comments so that it
is always added as a sibling to the comment instead of as a "uncle" when
a comment is found as the first leaf of a kid.
This patch fixes the usage of trailing commas in implicit tuples when
used in destructuring assignment, e.g. `x, = z`. In this context the
trailing comma is needed to preserve the tuple node, which is different
from e.g. implicit tuples in `do`-blocks. A trailing comma is allowed
(e.g. preserved from the source) for multi-item implicit tuples so that
e.g. `x, y, = z` can be used to signal that z contains more than two
items. Closes#58.
This patch simplifies the juliac compatible pipe-fork-exec
implementation for running git on the formatted text. Instead of
collecting all bytes and then writing to stderr we instead write
directly from the intermediate buffer to stderr. The drawback is that if
reading bytes fail we might have already written something to stderr,
but this should rarely, if ever, happen under normal circumstances.
This patch adds trimming of trailing whitespace inside of comments in
addition to the trimming of trailing whitespace in code. Note that
trailing whitespace inside of multiline is not trimmed since doing so
would change the content of the string.
Closes#50.
This patch removes trailing semicolons in blocklike contexts (`for`,
`if`, ...). Semicolons are left alone in top level contexts since they
are sometimes used there for output suppression (e.g. Documenter
examples or scripts that are copy-pasted/included in the REPL).
Semicolons before comments are replaced with a single space instead of
removed so that if the comments are aligned before, they will be aligned
after, for example
```julia
begin
x = 1; # This is x
y = 2 # This is y
end
```
will become
```julia
begin
x = 1 # This is x
y = 2 # This is y
end
```
Closes#34.
This patch introduces formatting for all blocklike constructs
(`if`/`try`/`function`/`begin`/`for`/`while`/...) such that inner block
always start and end with a newline character.
For example,
```julia
if x print("x") else print("y") end
```
will be reformatted as
```julia
if x
print("x")
else
print("y")
end
```
An exception is (currently) made for comments, for example
```julia
if x # comment
print("x")
end
```
will *not* be formatted as
```julia
if x
# comment
print("x")
end
```
even though the comment is technically inside the block.
Closes#35.
This patch introduces line continuation based indent for triple strings,
which typically span multiple lines without any explicit newlines in the
syntax tree (since they are hidden inside the string).
This result in the following changes, some of which are clearly
bugfixes:
Operator chains:
```diff
"""
abc
""" * """
-def
-"""
+ def
+ """
```
Operator chain as assignment right hand side:
```diff
x = """
-abc
-""" * """
-def
-"""
+ abc
+ """ * """
+ def
+ """
```
Implicit tuples:
```diff
"""
abc
""",
"""
-def
-"""
+ def
+ """
```
Note that single triple strings as a right hand side is excluded from
the indent rule, similar to having `if/try/let/...` blocks as a right
hand side.
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#41.
Octal formatting isn't as useful as hex formatting and it is also value
dependent (not just string-length dependent) which makes it a bit odd.
Octals are also very rare. One of the more common ones are filemodes and
for that case e.g. 0o755 looks better than 0o000755. Closes#40.
This patch make sure to keep the trailing semicolon in parens-block if
there is just a single item. Without the trailing colon the text would
be parsed as parens but not as a block (compare `(1)` vs `(1,)` for
tuples). Closes#38.
Kristoffer