Replies: 1 comment 1 reply
|
Would it also make sense for an external formatter to also target host languages? For example, as you say, we're not going to compete with {
languages = {
rust = {
extensions = [ "rs " ],
query_dir = "path/to/wherever", # say, only `injections.scm` exists
formatter = {
binary = "rustfmt",
extra_args = [],
},
},
json = {
# As currently defined
},
}
}That is, when Topiary sees a Rust source, it knows to use |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hey all, what are your thoughts on exposing a way to provide a formatter for the injection work, something like to allow external formatters for injections:
{ languages = { go = { extensions | default = ["go"], injection_formatter = "gofmt", # this grammar is only for injections # grammar = null, }, # ... }Motivation
In the same way that foreign languages are treated as a black box by tree-sitter grammars (a SQL string inside of a Rust AST/CST is just a string), foreign formatters should be treated in the same way
std::fmt::Formatterobfuscates the underlyingdyn Writeer.So whether the formatter is "local" or a CLI call for a foreign binary, they produce the same effect
topiary check-grammar) that contemporaries such astreefmtcan't really compete on because there is no lexical scopeAll reactions