Does it make sense to treat elements in a tuple/array literal as part of the @parameter object?

[IndianBoy42]

They are syntactically similar, and semantically not that different. I think there should be a text object for entries in lists/tuples/dictionaries, but the question is whether it should be in the parameter text object or another (@entry? @element)

[stsewd]

@IndianBoy42 do you have a file we can use to test what you mean?

[snezhniylis]

This can be a problem for dynamically typed programming languages such as Python and Lua where dicts/arrays/... can be passed directly as arguments.

function_call(1, [8, 38, 2, 5])

function_call({
  value1 = true,
  some_number = 35,
  child_table = {
    something = "something"
  }
}, true)

I find it very convincing to be able to select such objects. This way, I can quickly swap arguments, move some to their own local variables, etc.

But I also frequently find it lacking that there's no selector for dict entries / table members out of the box. Maybe there should be a query that does exactly what you propose, but named different. To be able to select all the delimited objects, including function arguments.

[stsewd]

This was already done in https://github.com/nvim-treesitter/nvim-treesitter-textobjects/pull/87/. But I agree that it makes sense to have those as a separate capture.

[IndianBoy42]

I think arguments could be made either way.

Either you just want a 'smarter' select inside comma separated list, or you really want to be specific about the semantic element

One of the troubles is the sheer number of different text objects you could define semantically

[mawkler]

I would also love to have a text object for comma separated items inside an array/list/table/dictionary. To me it makes sense to have a different capture group than @parameter, perhaps it could be called @field or @listItem?

[yochem]

I would go with @item or @element I think.