While [0.3](https://forum.nim-lang.org/t/10850) focused on correctness, the
overall theme for 0.4 is to polish the output, making it more regular and less
wasteful of indent and newlines.
The changes in formatting are enabled mainly by reusing the concepts of
"prefer-things-on-one-line" and "don't-waste-a-line" features already present
when rendering some nodes - in particular:
# If the whole function call doesn't fit with `=` but fits on its own on a
single line, do that:
let reallylongvariablename =
function(arg0, arg1, arg2)
# ...otherwise, "begin" the function call on the same line as `=`
let variable = somelongfunction(
arg0 = value,
arg1 = value2,
arg2 = value3
)
Run
Similarly, when formatting infix expressions, preference is given to
formattings that put the operator last while keeping operands on a line of
their own, thus avoiding non-structural line breaks in common situation:
# We could have fit "parts" of the expression after `and` here, but
# that would not represent the structure well
if L.buf[L.bufpos + 1] in {'0' .. '9'} and
(L.bufpos - 1 == 0 or L.buf[L.bufpos - 1] in UnaryMinusWhitelist):
discard
Run
We also learned to stack dot calls, as commonly seen in "builder"-style API:s:
let x =
somevariable
.function0(32)
.function1(42)
Run
When formatting, `nph` tries to keep apart "simple" things like literals and
identifiers from complex expressions - when something is "simple", it will use
a more compact formatting to ensure that things like lists of numbers don't end
up taking too much vertical space - this release saw the addition of `.` to the
list of "simple" things, such that introducing a module or object name
(`mymodule.symbol`) doesn't cause an explosion.
Finally, [NeoVim](https://github.com/arnetheduck/nph/pull/38) editor
integration was contributed by foxoman 🎉
Unless significant bugs appear, I'm hoping to keep the 0.4 formatting stable
for some time for the format to sink in and for significant issues to be
discovered, while at the same time avoiding disruption.
The plan is to increase the time between each release for each release that
passes until we get to something that feels really good and deserves a "stable"
moniker, which hopefully isn't too far off.
In terms of areas of future improvement and possible contribution, doc comments
probably stand out - this work however should probably be undertaken in concert
with doc generation tooling so that both `nph` and `nim doc` end up following
similar conventions - the comment handling in the parser remains one of the
most fragile aspects of automated formatting and documentation tooling alike
and would greatly benefit from a holistic approach.
