-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(topiary-queries/scm): Fixed invalid formatting of field_definition
s
#826
base: main
Are you sure you want to change the base?
Conversation
I wasn't sure where to put these two test cases as |
The fact that |
Ok, should I just add test cases to it arbitrarily. it may be better to expand test cases into their own files and have the test suite use a set of files. |
I also see that topiary formats the tree-sitter s-expressions as (foo
(bar)
) instead of the trailing parentheses I see everywhere else: (foo
(bar)) Is that intentional? |
I think this was just the style we adopted at the time and it's stuck. There was no particular reason, as far as I remember. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution 🙏
I've made a few suggestions and I have a couple of more general comments, from the PR discussion:
-
It would be great if you could add test cases to
topiary-cli/tests/samples/{input,expected}/tree_sitter_query.scm
. Feel free to add them arbitrarily; it doesn't matter that it diverges from our OCaml rules. -
For the time being, I think we should stick with the Algol-style indentation, rather than Lisp-style. That is:
; Algol-style (foo (bar (quux) ) ) ; Lisp-style (foo (bar (quux)))
I think there's a strong argument to switch to Lisp-style, but I think that warrants an issue -- feel free to create one -- so the Topiary Team can consider it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your changes 🙏
This is very close to being correct, however there's a small bug when multiple captures/identifiers appear after the predicate in a multi-line context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies; looks like I was too quick to approve!
There is one more edge case, that the CI uncovered. When a predicate has nothing after it (captures, identifiers or strings), then an errant space ends up in the output:
(tag_specification) @prepend_delimiter
(#delimiter! "| ") ; sic
- (#multi_line_only!)
+ (#multi_line_only! )
)
@mkatychev It's an easy fix; I'd push it myself, but I doubt I have appropriate access to your fork. This rule is both redundant and adding the errant space when there are no parameters to the predicate: (predicate
(predicate_type) @append_space
) It can simply be removed 👍 |
@Xophmeister I've definitely had maintainers push directly to my branches before. P.S. |
* prevent invalid formatting of `field_definition` that followed an `identifier` * `predicates` parameters are now separated by a `spaced_softline` allowing long predicates to be broken up
Co-authored-by: Christopher Harrison <Xophmeister@users.noreply.github.com>
b670b35
to
9c5abf6
Compare
Fixed invalid formatting of
field_definition
sDescription
field_definition
that followed anidentifier
predicates
parameters are now separated by aspaced_softline
allowing long predicates to be broken upChecklist
Checklist before merging: