Add @prepend_antiline/@append_antiline

[rpost]

Hi all,

First of all: Topiary is great!

I'm currently experimenting with formatting java with topiary and I miss something similar to https://topiary.tweag.io/book/reference/capture-names/horizontal-spacing.html?highlight=anti#append_antispace--prepend_antispace but for vertical spacing.

My use case: I want all block-s to be formatted like this:

if (myCondition) {
}

void myMethod() {
}

Like we used to format blocks in java: with newline after closing brace. As usual when there is general rule there is also exception:

try {
} catch(Exception e) {
} finally {
}

It would be very handy to express general rule as:

  (block
      .
      "{" @prepend_space @append_hardline @append_indent_start
      (_)*
      "}" @prepend_hardline @prepend_indent_end @append_hardline
      .
    )

and then enumerate exceptions which doesn't have trailing newline:

(try_statement
  (block
      "}" @append_antiline
      .
    )
)

Without this I have to enumerate every possible combination of parent<->block and apply rules individually.

[Xophmeister]

Thanks for your suggestion 👍

I think the way we'd normally do this is by specifying a rule that applies formatting within the block, like this:

(block
  .
  "{" @append_spaced_softline @append_indent_start
  "}" @prepend_spaced_softline @prepend_indent_end
  . 
)

Here I'm using spaced softlines for the case where you have a one-liner that gets formatted like { foo }, which is a common pattern.

Then, for vertical spacing between nodes, one could use an alternation:

(
  [
    (conditional)
    (for_loop)
    (try_catch_block)
    (etc_etc)
  ] @append_hardline
  .
  (_)
)

Or, depending on how uniform these node types are, separate rules for each...which is probably more likely, as those node types will presumably need fine-tuning formatting of their own. For example, adding the space between the keyword, etc. and the block.

I think the case for an "antiline" makes sense when the grammar is very regular, with a handful of exceptions. Your Java example might fit that pattern, so it's worth thinking about, but how I describe above may make for more tractable queries...