Means to control configurability of topiary formatting

[mkatychev]

similar to configuring rustfmt.toml, topiary could have certain queries be mutually exclusive or toggleable through languages.ncl or a topiary.toml.

For the example below I'll use toml to mirror the way rustfmt.toml does configs:

mutual exclusivity could be used for enum specifications such as rustfmt brace_style:

Brace style for items

• Default value: "SameLineWhere"
• Possible values: "AlwaysNextLine", "PreferSameLine", "SameLineWhere"
• Stable: No (tracking issue: [#3376]1)

The query file for rust.scm for supporting a brace_style enum would look something like this:

(function_item
  (where_clause)? @do_nothing
  .
  (block
    (#config_enum! "brace_style" "SameLineWhere" @default)
    .
    "{" @append_spaced_softline @append_indent_start
    "}" @prepend_spaced_softline @prepend_indent_end
    .
  )
)

(function_item
  (where_clause)
  (block
    ; @default does not have to be respecified
    (#config_enum! "brace_style" "SameLineWhere")
    .
    "{" @prepend_spaced_softline @append_indent_start
    "}" @prepend_spaced_softline @prepend_indent_end
    .
  )
)

(function_item
  (block
    (#config_enum! "brace_style" "AlwaysNextLine")
    .
    "{" @prepend_spaced_softline @append_indent_start
    "}" @prepend_spaced_softline @prepend_indent_end
    .
  )
)

(function_item
  (block
    (#config_enum! "brace_style" "PreferSameLine")
    .
    "{" @append_spaced_softline @append_indent_start
    "}" @prepend_spaced_softline @prepend_indent_end
    .
  )
)

This would allow a topiary.toml to allow an end user to configure their styling in a similar way:

[rust]
brace_style = "PreferSameLine"

[Xophmeister]

The end result of this is not dissimilar to the feature proposed in #839. They use different mechanisms to achieve this end, but it is ultimately about formatting configurability.

One of the stated design goals of Topiary is:

• For end users -- i.e., not formatting style authors -- the formatter should:
  • Prescribe a formatting style that, while customisable, is uniform and "good enough" for their codebase.

That is, the philosophy is that the formatting rules should not be configurable but rather, if users have particular needs, they have the means to customise queries (which is relatively easy) to meet those needs. This raises the bar enough such that one doesn't end up with a proliferation of different styles -- i.e., over the space defined by configuration options -- which leads to bike-shedding about the "one true formatting style".

That's not to say that we can't be persuaded otherwise. Configurability has come up twice now; we're open to discussion -- and thank you for starting this, here 🙏 -- but I think the argument to implement such a feature would need to be quite strong.

[mkatychev]

Agreed, I think my general thought about this is that default configs typically have the moral high ground even in configurable formatters (rustfmt.toml non default configs are quite uncommon for instance). If one (maintained) format is the philosophy here, I'm 100% on board.

My impetus for this discussion mainly stemmed from #828 in the sense that the formatting rules maintained should, crassly put, pander to the lowest common denominator of a community.

I think the argument to implement such a feature would need to be quite strong

I don't intent to persuade you one way or the other as your rationale is more than satisfactory! I'm happy to close this discussion or leave it open.

[Xophmeister]

It's a good discussion, so I think it's worth keeping open to see if anyone else offers up similar or alternative points of view.

I think your point about #828 is a good one: In that case, it does indeed look like Lisp-style formatting is used for Tree-sitter queries more often than not and that pushes the needle towards us changing it (rather than providing both options).