Adding configuration for new, tree-sitter based indentation logic#608
Adding configuration for new, tree-sitter based indentation logic#608chfritz wants to merge 2 commits intoatom:masterfrom
Conversation
99f24f3 to
0803731
Compare
…core See this PR in atom/atom: atom/atom#18321. Once the other PR is merged, this one then fixes atom#594. Updated: now without the need for a callback function as part of configuration
0803731 to
d826f8f
Compare
|
Now that atom/atom#18321 is merged, merging this PR will enable the new tree-sitter based indentation for javascript. See https://github.com/atom/atom/pull/18321/files#diff-2b51afa53cf043f5ac43123d778c7717f22c18ba3debe76fd34f4e1d0da9c416 for samples of this indentation. One of the main motivations for it was unbalanced closing brackets, which currently cause very bad indentation, e.g.: This is happening because the current indentation logic in Atom is only based on the previous line and doesn't count all opening scopes (as was proposed here). This can result in negative indentation as seen above. The new logic is using the parse tree provided by tree-sitter to get things like that right: FYI, @sadick254 . |
|
The failing tests don't seem to be related to the changes in this PR. |
|
@chfritz am working on resolving those errors. We should be good to go once resolved. |
|
Hi @sadick254 , I saw that atom 1.59 was released, including the tree-sitter based indentation logic. That's exciting! Now once we can merge sort out the issues with this PR and merge it, people will see the benefits and we should be able to close a number of indentation related issues. Let me know how I can help. |
Description of the Change
This adds the configuration needed for the new, tree-sitter based indentation logic. That new logic is implemented in this PR in atom/atom: atom/atom#18321.
Once that PR is merged, this one then fixes #594.
Alternate Designs
Since this only adds configuration, the real discussion about alternate design is in atom/atom#18321.
Benefits
Fixes several indentation issues that all arise from the fact that the previous regex based logic was inductive (i.e., only based on the previous line). This prevented the implementation of certain patterns that seem preferred by users (and seem more correct). See, e.g., atom/atom#6655 and others.
Possible Drawbacks
I'm not a huge fan of how I'm adding the functional configuration (precedingRowConditions) to the grammar. This clutters the namespace in that object a little (but not much). Other than that I don't see any downsides.-- this has now been improved to whereprecedingRowConditionsis no longer required.Applicable Issues
atom/atom#6655
#476
#560
to name a few.