Support custom textobjects via user configurable tree-sitter captures and keymappings?

[connorlay]

According to the documentation, the following tree-sitter captures are recognized as textobjects:

• function.inside
• function.around
• class.inside
• class.around
• parameter.inside
• comment.inside
• comment.around

I'm interested in adding a couple new textobjects to better support Elixir's ExUnit DSL, either to Helix itself or as part of my personal config:

• test.inside
• test.around

Looking at the implementation of textobjects in Helix, it seems like most of the code could be reused to support these new textobjects. Given that, would it be possible to support any arbitrary capture as a textobject, exposing that as a language and keymap configuration option?

[the-mikedavis]

I think this is a good idea. It will be hard to find a good way to configure the keybind for it though until we have a more general-purpose configuration language (toml config is temporary). I wouldn't mind having test textobjects in core though since they're so ubiquitous across languages. The mat/mit/[t/]t bindings would work nicely.

[connorlay]

I started a draft PR implementing mat/mit/[t/]t using Elixir queries as the initial use-case #2807

[connorlay]

@the-mikedavis Now that mat/mit/[t/]t have available in core, I'm wondering if we should add support for groups of tests maT/miT/[T/]T via test_group.inside and test_group.around:

describe "a group of related tests" do # test_group
  test "the first test" do # test
    # ...
  end

  test "the second test" do # test
    # ...
  end
end

What do you think?

[the-mikedavis]

I think this would definitely be useful for Elixir and probably Ruby as well (context in RSpec) but I'm not sure it's common enough in other languages to fit well into core. Afaik not too many languages have grouping for test cases

[connorlay]

Out of curiosity, what are the tradeoffs of adding more language-specific textobjects to core? I can think of a couple myself.

Downsides of adding language-specific textobjects:

• more textobjects in core increases the maintenance surface area for contributors
• more keymappings are used by the default configuration
• more information displayed in the textobjects modal, some of which may not apply to the current buffer

Downsides of not adding language-specific textobjects:

• fragmentation of query capture names in the community, which is a problem I noticed with Neovim
• maintainers of tree-sitter grammars and queries have more places they need to look when making potentially breaking changes
• new users of Helix might have to rely more on plugins to get all of the features for their language of choice

One potential solution I can think of would be to conditionally enable textobjects and keymappings only if the given capture has been defined in the query file for the given language.

[the-mikedavis]

With the core we try to be lean but featureful - so adding features that provide a consistent experience across languages and workflows (e.g. tree-sitter, LSP, and DAP based features). I think language-specific textobjects are a good thing overall but having default bindings for them conflicts with being lean a bit. I think this is something we might be able to support in core (or with a bit of configuration on the user-end) with a more general-purpose config language