cursorless
cursorless copied to clipboard
Add language support for `.talon` files
Now that there is a tree-sitter for Talon files, we should leverage this to add proper Cursorless support for Talon files
See https://www.cursorless.org/docs/contributing/adding-a-new-language/
Scope types
"command"
"state"
"name" / "key"
"value"
"body" / "inside" (punt on "inside" for now)
"state"
"callee"
"arg"
"call"
"condition"
Just FYI, I've started working on this on a branch. I will push it when it gets a bit closer to completion :)
Developing in this branch: https://github.com/phillco/cursorless/tree/kotlin-talon
Most of the functionality is working (with a couple of notes), just need to record the tests.
Quirks with the grammar I noticed so far:
- Some of the notes like
tag()andsettings()have parentheses in the names. Cursorless has difficulty matching them. - The
-node inside of the settings block is a sibling to the other rules, so we can't easily target just the rules without writing a custom matcher. It would be better if there was a parent node for all of the rules. - @AndreasArvidsson suggested that if there is a general convention of using left/right parent blocks for the left hand side/right hand side of things we could reduce the number of matches needed, e.g. we could reduce this:
value: [
"assignment[right]",
"match[pattern]",
"include_tag[tag]",
]
- For the type names with parentheses, that feels like a Cursorless-specific problem, so I'm not sure worth changing the parser. Also, I believe @AndreasArvidsson mentioned he has a fix for those now, and the real problem was probably unnamed nodes?
- Filed https://github.com/wenkokke/tree-sitter-talon/issues/11 for second point
- Filed https://github.com/wenkokke/tree-sitter-talon/issues/12 for third point
I think Andreas' point was that names just shouldn't have special symbols in them regardless. Also we updated the regex but they still didn't work in Cursorless, so if there's another fix I'm not aware of it
Maybe cursorless patterns don't support unnamed children?
Fair point re special chars in type names; I'll file to see what makes sense
On second thought, it's actually quite common for node types for unnamed nodes to have special chars. For example, ", ,, (, etc, so unless we want to argue for removing those everywhere, I'm not sure I see a good argument for removing them here?
You are right that symbols often have their own character as their type. I'm quite sure that the Cursorless pattern matcher would not support "type.." and similar.
Developing on this branch: https://github.com/cursorless-everywhere/cursorless/tree/other-languages along with #949 #817 #985
@phillco @pokey Except for the whitespace getting included in the match values (that we soon will have a new release of the Talon tree sitter for) I think this pr is done :)