migrate Go keys and values to treesitter

[josharian]

This doesn't handle all uses of key and value.

Missing still are assignment statements (name, value), function signatures (name, value), and possibly other places (perhaps type declarations?).

It does handle all existing uses of key, value, and name, though, so we can start here.

The handling of multiple return values is complicated, particularly around the handling of comments and removal ranges. It would be nice to find a simpler approach.

Checklist

• [ ] I have added tests
• [ ] I have updated the docs and cheatsheet
• [ ] I have not broken the cheatsheet

[josharian]

I haven't added any tests yet. Before I did that, I wanted to get a round of feedback about the behavior, so that I don't waste time adding tests with the wrong behavior.

There are a lot of tests to add.

To make it easier to get initial feedback I have included two videos of the scope visualizer. They go by fast but you can pause as needed. :)

A lot of the same considerations about comments, only-one vs many (and for many, first-vs-rest), removal ranges, etc. apply to the other uses of name and value, so it'd be good to get happy with the behavior and implementation before I continue with those.

(A surprising amount of development time is packed into not very many lines with .scm files. :P)

[josharian]

return values:

https://github.com/cursorless-dev/cursorless/assets/67496/e15d9ba4-7063-4526-bc0c-4c215cb779ca

[josharian]

keys and values in maps and lists:

https://github.com/cursorless-dev/cursorless/assets/67496/7b7675ef-1fd2-4af1-90bb-46d6668f4413

[pokey]

return values:

visualize_value.mov

Looking pretty good! One thing we're doing in other places is to have a scope that is the parent of the other scopes, whose domain is the entire statement and whose range is from the first return value to the last. See eg the name scope in .scm, and the comment proposing that behaviour https://github.com/cursorless-dev/cursorless/issues/1631#issuecomment-1676912684. Note that we only have that parent scope when there is more than one return value, otherwise you get useless nesting

Also, it's tough to tell what your iteration scopes are actually doing, but I think we'd want one iteration scope for iterating the values of one return statement when it has more than one return value, and a bigger iteration scope consisting of the function body

[pokey]

keys and values in maps and lists:

visualize_key_value.mov

this looks great!

[josharian]

I need to take another pass over this, marking as draft in the interim.

[pokey]

update: I'll have a look to see if there's stuff we can easily pick up to take this one home

[josharian]

update: I'll have a look to see if there's stuff we can easily pick up to take this one home

Sounds good, thanks. I'm eyeball deep in other stuff, so I don't anticipate much cursorless bandwidth for a fair while.

[pokey]

Removing myself as assignee so that someone else can pick it up