[Mini.ai] v:count implementation with custom text objects

[Gazareth]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Module(s)

mini.ai

Description

Hi, following on from #261 I have been attempting to create text objects for w, W and p. I have made some headway with w, it currently looks like this (updated: 20230316):

          w = { '[^%w@_]*%f[%w@_]()()[%w@_]+()%s*()[^%w@_]*' },

The problem is when I input 2yiw for example, it seems to want to yank only the second "word". Default vim behaviour would be to select both the current "word" and the next one. I'm guessing this is to do with the way v:count is implemented for text objects?

I don't know whether this is a bug or a feature, for example I know with bracket-type text objects, the behaviour of v:count with a count of 2 would be to select the brackets surrounding the ones you're in. (i.e. to expand outwards). But I think for things like words and WORDs it makes sense to expand forwards.

I'm wondering if it makes sense for text objects to be able to specify how they interact with v:count?

[echasnovski]

I'm wondering if it makes sense for text objects to be able to specify how they interact with v:count?

Textobject interacts with v:count as if user consecutively selected it v:count1 times. So v3a) is identical to va)a)a).

How textobject behaves in consecutive selection depends on search_method and textobject specification itself. If search_method contains "cover" (like cover, cover_or_next, etc.), it will attempt to find smallest region which covers current selection (start is before, end is after) and matches specification.

In your case this pattern doesn't seem to match two words separated by whitespace (like abc def), so it can not find covering match. If you use default search method (cover_or_next), it will attempt to find next match (start is after, end is after) which is what happens from your description.

I am honestly not sure how to make it better using Lua patterns. One other approach might be to use function which returns array of regions, but it might be computationally expensive and not trivial.

[Gazareth]

What about if there was a new spec: gen_spec.consecutive_pattern(). This would take a pattern, similar to current behaviour when you don't use a spec function, but when it attempts to find a covering match, it joins multiple instances of pattern together, perhaps with a 'separator' pattern?

[Gazareth]

Another option, or another part of this implementation could be to introduce a new search method, cover_consecutive or something like that

[echasnovski]

Sorry, I don't think introducing new gen_spec entry or search method to solve this kind of case meets a feature - maintenance trade off.

[Gazareth]

No worries. So do you think there's no scope for mini.ai to handle this kind of interaction? Or it just depends on implementation?

[echasnovski]

No worries. So do you think there's no scope for mini.ai to handle this kind of interaction? Or it just depends on implementation?

For more complex definitions of text object, there is a function form instead of Lua patterns. It's API is a bit overcomplicated, but that is the price to allow flexibility without much extra source code. For more hands-on example see argument textobject.