Do you want me to make that change [to the Forgejo actions] as part of this PR?
Yes. I just confirmed that the reformatted YAML files work when I run CI locally, and I'd rather do the…
Do you know whether we can also apply this style to the YAML files that specify our Forgejo actions? If you're not sure, I can try it out later by [running continuous integration locally](https://c…
I've done the following checks:
- Skimmed through all the file diffs to confirm that the pull request only makes the intended changes of de-indenting blank lines and adding final carriage…
My Files changed tab still seems to be showing a diff with pull request #117 (commit 978f70a), even though pull request #118 (commit 2c8c09d) has now been merged. Any idea how to correct that?
I like the way you've added explicit verbs to these bullet points!
Flagging the inconsistent bracket formatting for later. Right now, this would be formatted as { index, value } elsewhere, but during review we discussed potentially changing this convention in the future.
When I originally wrote this test, it bothered me that the identifiers sphere0 and sphere1 were assigned but never tested. The new, more informative indexing error message makes them part of the test, which is very satisfying.
This looks ready to go! Excited to have these new regulators available.
Whoops, this was meant to be an additional request for changes, not an approval.
Very minor: the rest of the list is formatted as one sentence per list item, with no final period. It would be nice to keep that consistent.
Flagging this as a potential mistake because it adds a new change to the pull request, rather than reverting one of the changes in commit c0e6ebf, and I don't see an obvious reason for this pull request to touch it. Could you confirm that this change was deliberate if it was, and revert it if it wasn't?
I'd indent this line by two tabs to match the convention you've used for other multi-line expressions. This won't affect the string, because the string continuation escape absorbs all subsequent whitespace, resuming the string at the next non-whitespace character.
Okay, this looks mostly finished to me! I just have one question and one small request involving the reformatting in commit 50c51ca.
So I'd like to just stick with 80, thanks.
Sounds good!
In the meantime, I would be perfectly happy to do either or both of the following two things, but they might each be a bridge too…
Ok will move message helper up a bit and comment it. As far as the name, I would like to avoid undue verbosity for a private local helper, I will see if I can sharpen it a bit without lengthening…