Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft PR to try out Runic for code formatting after discussion with @SimonDanisch.
Currently this PR only contains the "raw" Runic formatting with no manual changes, and only for files in
src
. When applying Runic to other code bases (for example Documenter.jl in JuliaDocs/Documenter.jl#2591 JuliaDocs/Documenter.jl#2564) there are a couple of things one might want to check manually (not for correctness, but for aesthetics).Runic adds
return
in front of the last expression in function bodys but this doesn't recurse intotry
andif
, for example. Therefore, one might want to change e.g.to
depending on what you prefer.
In other cases one might want to be more explicit with what is to be returned (which Runic formatting forces you to do in a sense). For example, in this repo there are many cases of this pattern:
which after formatting now become
The API of
plot!
is to returnp
(right?), but here it couples directly to the return value oflines!
. Personally I would then rewrite this intojust to make it a bit more clear, and to make sure that if the API of
lines!
changes it doesn't affect the return value ofplot!
.If you choose to adopt Runic I think the way we did it in Documenter.jl is a good way: First merge a PR with the "raw" formatting and then make another PR with manual changes just to make it clear what changes are Runic's and what changes are manual. These commits can then be added to a
.git-blame-ignore-revs
file so thatgit blame
doesn't show these commits, see https://github.com/fredrikekre/Runic.jl?tab=readme-ov-file#ignore-formatting-commits-in-git-blame for details.The changes here were generated with what I hope to be Runic version 1.0.0. I looked at the patch myself and I didn't see anything I would consider Runic bugs, but I would still be curious if you have any feedback or questions about the actual style.