Beta-testing 'mini.ai'

[echasnovski]

Please leave your feedback about new 'mini.ai' module here. Feel free to either add new comment or positively upvote existing one.

Some things I am interested to find out (obviously, besides bugs):

• Are configuration and function names intuitive enough?
• Are default values of settings convenient for you?
• Is documentation and examples clear enough?
• What is your opinion about default textobjects (for punctuation, digits, and whitespace)? At the moment it mimics 'targets.vim' idea about separator textobject - the a variant includes only one of the edges (the maximum right ones, to be precise). Although useful in many cases (like _ in snake case variables allows da_ to delete word while preserving snake case), it might be not useful for some characters in most situations (like | seems to rarely serve as separator and more like surrounding). I see at least three ways to solve this:
  • Leave it as is. It means that users are encouraged to manually define custom textobjects to include both edges in a textobject. It is what currently is done with at least three different ways to achieve this. This is the way if there is little consensus about what character should be treated as surrounding by default.
  • Add new builtin surrounding to include both edges in a textobject. This is the way, if there is a strong consensus about certain character (like |) being more of a surrounding instead of separator and of which type (balanced or non-balanced).
  • Add new default builtin surrounding to act by default. Maybe some people like include both edges by default (I know I was at first, but then changed my mind because of how useful including only right edge is). Completely not opposed to this, but any options should be considered carefully. This is the way of adding new option.

Thanks!

[DeadlySquad13]

Thanks for your plugin! I have dreamed about lua textobject plugin for so long. I have come from reddit and some people were requesting 'next' and 'last' operator types. You were saying that they're rarely used but, as for me and, I suppose, for community too, it's a must have feature.
I'm a long time user so I have mastered it and it's really cool to edit something far away with a few keystrokes without even jumping to location. Editing feels like magic!
Hope you will overthink your decision about not adding these types of operators!

[echasnovski]

Thanks for your plugin! I have dreamed about lua textobject plugin for so long. I have come from reddit and some people were requesting 'next' and 'last' operator types. You were saying that they're rarely used but, as for me and, I suppose, for community too, it's a must have feature. I'm a long time user so I have mastered it and it's really cool to edit something far away with a few keystrokes without even jumping to location. Editing feels like magic! Hope you will overthink your decision about not adding this issue!

Thanks!

As I said on Reddit, I've never even once used that feature and didn't feel like missing much. I did got some use cases from comments. It feels that most of the time it is about enabling dot-repeated editing in one direction. This is supported with default v:count without needing to type extra n.

So with 'targets.vim' foo("bar", 2, []) after typing ^cina100<esc>.. will become foo(100, 100, 100). With 'mini.ai' it is possible with ^cia100<Esc> followed by c2ia100<Esc>. Is it something that you'll find acceptable?

I'll be really grateful if you could provide another examples of how you use il/al/in/an. It can help me understand the requirements better.

[DeadlySquad13]

Thanks for your plugin! I have dreamed about lua textobject plugin for so long. I have come from reddit and some people were requesting 'next' and 'last' operator types. You were saying that they're rarely used but, as for me and, I suppose, for community too, it's a must have feature. I'm a long time user so I have mastered it and it's really cool to edit something far away with a few keystrokes without even jumping to location. Editing feels like magic! Hope you will overthink your decision about not adding this issue!

Thanks!

As I said on Reddit, I've never even once used that feature and didn't feel like missing much. I did got some use cases from comments. It feels that most of the time it is about enabling dot-repeated editing in one direction. This is supported with default v:count without needing to type extra n.

So with 'targets.vim' foo("bar", 2, []) after typing ^cina100<esc>.. will become foo(100, 100, 100). With 'mini.ai' it is possible with ^cia100<Esc> followed by c2ia100<Esc>. Is it something that you'll find acceptable?

I'll be really grateful if you could provide another examples of how you use il/al/in/an. It can help me understand the requirements better.

Yes, you're right. It's mostly about convenient dot repeat. But I also use it to quickly edit, for example, object contents. Suppose you have a function:

vim.tbl_extend('error',
{
  a1 = b,
  a2 = c, 

  s1 = 3
}, {
  s2 = 4
})

And I usually edit it with a help of textobject: firstly I use ci{ to change contents of a first list while inside of it, then issue cin{ to edit second list without moving to it. Of course it works backwards (from second to first with cil{).
Unfortunately, what you have shown is barely acceptable: well, it does work, but you:

1. Waste a lot of keystrokes (after all this plugin is all about saving them).
2. Have to count a number beforehand which distracts fluid experience.
3. Works only if the contents of a both changes are the same, otherwise, you have to move. In my example objects can be completely different.

Of course, your work is splendid, you're free develop your plugin in whatever direction you think is better but for me advanced configuration features are not as important as these basic operators.

[echasnovski]

Thanks so much for feedback and example. That really helps!

I think I might have found a way to make work in a coherent way by introducing new search methods prev and next (maybe even add nearest for good measure): they won't give preference to covering region, only selecting closest previous or next region. With this, it will be easy to add those.

[DeadlySquad13]

Thanks so much for feedback and example. That really helps!

I think I might have found a way to make work in a coherent way by introducing new search methods prev and next (maybe even add nearest for good measure): they won't give preference to covering region, only selecting closest previous or next region. With this, it will be easy to add those.

I wish you good luck! You've been asking about criteria - I have also remembered that you can add count before operator, so in the previous example you would be able to jump from first to third object with a c2in{.

[milanglacier]

I already uses mini.ai now. Compared to targets.vim, it works pretty better in some text objects like aa, ia, etc
and even a}, i}, sometimes targets doesn't recognize text objects across multiple lines well.
I never think AI is useful. So did for nl once. And not until read the reddit thread did I realize that how can one utilize the potential of nl. But I do agree that nl may be useful now after reading those threads.

[echasnovski]

I already uses mini.ai now. Compared to targets.vim, it works pretty better in some text objects like aa, ia, etc and even a}, i}, sometimes targets doesn't recognize text objects across long line well. I never think AI is useful. So did for nl once. And not until read the reddit thread did I realize that how can one utilize the potential of nl. But I do agree that nl may be useful now after reading those threads.

Thanks for the feedback, this is really helpful. And totally aligns with my experience about both AI and nl (and the usefulness of the latter). I am already working on nl.

(Offtopic: that is some seriously evolved Neovim config you've got there! Although, I am not sure about using cover_or_nearest: I added it for completeness sake, but don't really like its usability. After you've used it, could you please share your thoughts about it?)

[milanglacier]

I

I already uses mini.ai now. Compared to targets.vim, it works pretty better in some text objects like aa, ia, etc and even a}, i}, sometimes targets doesn't recognize text objects across long line well. I never think AI is useful. So did for nl once. And not until read the reddit thread did I realize that how can one utilize the potential of nl. But I do agree that nl may be useful now after reading those threads.

Thanks for the feedback, this is really helpful. And totally aligns with my experience about both AI and nl (and the usefulness of the latter). I am already working on nl.

(Offtopic: that is some seriously evolved Neovim config you've got there! Although, I am not sure about using cover_or_nearest: I added it for completeness sake, but don't really like its usability. After you've used it, could you please share your thoughts about it?)

I do haha, just find this option is interesting and simply want to give it a try. Will try to find some interesting scenario.

[echasnovski]

@DeadlySquad13, @milanglacier, I've added support for an/in/al/il mappings. They are basically a/i textobjects but with temporarily set search method to new next/prev.

Even during this limited time of testing I indeed found it useful to use cina to edit next argument (instead of not-so-intuitive c2ia which also doesn't quite work outside function call).

[JoseConseco]

@echasnovski the prev operator works great - it can be dot repeated no problem. But if we run: dina :
https://user-images.githubusercontent.com/13521338/181919302-9921ff71-0242-4018-88dd-7ae1f201b2f4.mp4
mini ai skips next arg, and jumps 2x forward. Cool addition.
btw. What would be fastest way to add additional mapping : A - which would work as aa (around arg, without removing aa) ?

[echasnovski]

@echasnovski the prev operator works great - it can be dot repeated no problem. But if we run: dina : https://user-images.githubusercontent.com/13521338/181919302-9921ff71-0242-4018-88dd-7ae1f201b2f4.mp4 mini ai skips next arg, and jumps 2x forward. Cool addition.

Well, this happens because the second time cursor is already on the (previously) second argument and dina skips it. Imagine you didn't make dina beforehand and just put cursor there, what would your expectation be after hitting dina? I think dia in this case has the same effect (with default search method, of course).

[JoseConseco]

I would expect to be able to . repeat dina - without skipping args:
https://user-images.githubusercontent.com/13521338/181919547-ef71ac20-22f6-4676-a671-3b8baccd738f.mp4
I think this is how it worked in targets.vim ?
Ah, ok I can see now - if I nudge cursor to left, after first dina, then dot repeat works as expected

[echasnovski]

btw. What would be fastest way to add additional mapping : A - which would work as aa (around arg, without removing aa) ?

Using mapping without noremap seems to be the way to go here:

vim.api.nvim_set_keymap('x', 'A', 'aa', { noremap = false })
vim.api.nvim_set_keymap('o', 'A', 'aa', { noremap = false })

However, you loose A in Virtual-Block mode.