mini.surround: Support auto-target similar to vim-sandwich

[lervag]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.surround

Question

vim-sandwich has a concept of an "auto target", e.g.:

					*<Plug>(sandwich-delete-auto)*
[count] <Plug>(sandwich-delete-auto)
	Delete the [count]th closest surroundings from the cursor.
>
	[foo(bar)baz]  cursor is on "bar"

	--  sdb --> [foobarbaz]
	-- 2sdb --> foo(bar)baz
<
	<Plug>(sandwich-delete-auto) is available in normal mode. It is mapped
	at sdb in default.
>
	nmap sdb <Plug>(sandwich-delete-auto)

I've found this to be very useful and I believe I use it more or less everyday. I'm curious, does something similar exist in mini.surround? Or do you have a suggestion of a different (perhaps even better) workflow? May this be a useful feature request?

[echasnovski]

I don't remember having this brought or even knowing about it when I used 'vim-sandwich' prior to 'mini.surround'. At the moment, it is not possible to achieve in 'mini.surround' to 100% (at least without major hackery). There is a way to group some surroundings under a single id (see, for example, implementation of b identifier), but not all of them.

I'll think a bit more it, but it doesn't look like a good fit in 'mini.surround', as it would require a new built-in surrounding id (which is a bit breaking) and non-trivial implementation specifically for that surrounding.

[lervag]

Thanks for considering this. I think it can be useful to consider the relevant mappings here and what we want them to do. Let's focus on normal mode mappings, because I think this is basically only useful there.

• There is no "auto target" for the add command in vim-sandwich. I believe I will use sas for saiW. The s target is currently the letter s and it's not so useful. Surrounding the current word is something I often do.
• srr will currently replace the surrounding "r"s, which is also not so useful IMHO. Thus, I think adding a custom target for "r" can be very useful. I guess I could make it a synonym for b, although if it would be possible to have something that combines b and t and possibly even f, then that would be optimal.
• sdd currently deletes surrounding ds. As above, I don't think that is very useful and I would instead want the d target to do something more useful similar to my above discussion.

So, I'm looking for a way to make a custom surrounding that combines some of the existing ones. Would that be possible?

[echasnovski]

• There is no "auto target" for the add command in vim-sandwich. I believe I will use sas for saiW. The s target is currently the letter s and it's not so useful. Surrounding the current word is something I often do.

Here second s in sas won't be considered as a surrounding identifier but a textobject/motion. If you want to use s instead of iW, then creating an Operator-pending mode mapping is a better approach here.

The issue with clean implementation of "repeating" keys like srr and sdd is that the concept of surrounding identifier is the same for all sa, sd, sr, sf / sF, and sh. So defining own r and d surrounding ids will also make them work for other actions. Not that it is bad per se, but at least something to consider.

So, I'm looking for a way to make a custom surrounding that combines some of the existing ones. Would that be possible?

Only if the result can be expressed according to the specification. For brackets, quotes, and similar known in advance pairs it is fairly straightforward. Something beyond that - probably not and/or requires black magic coding. And I am not sure accounting for that use case specifically will be added to 'mini.surround'.

[lervag]

• There is no "auto target" for the add command in vim-sandwich. I believe I will use sas for saiW. The s target is currently the letter s and it's not so useful. Surrounding the current word is something I often do.

Here second s in sas won't be considered as a surrounding identifier but a textobject/motion. If you want to use s instead of iW, then creating an Operator-pending mode mapping is a better approach here.

I think I was unclear. I'm using the following config right now, and it seems to work well for me.

keys = {
  { "sas", "saiW", remap = true },
},

With this, I can do e.g. sas" to add quotes around the current word. I'm not sure if I'm going to use this, perhaps I'll adjust it. But it works as expected.

The issue with clean implementation of "repeating" keys like srr and sdd is that the concept of surrounding identifier is the same for all sa, sd, sr, sf / sF, and sh. So defining own r and d surrounding ids will also make them work for other actions. Not that it is bad per se, but at least something to consider.

Yes, agreed, it's important to know about this "side effect". But I think it's OK.

So, I'm looking for a way to make a custom surrounding that combines some of the existing ones. Would that be possible?

Only if the result can be expressed according to the specification.

I'm currently experimenting with this version

local catchall = {
  { '%b()', '^.().*().$' },
  { '%b[]', '^.().*().$' },
  { '%b{}', '^.().*().$' },
  { "'.-'", '^.().*().$' },
  { '".-"', '^.().*().$' },
  { '`.-`', '^.().*().$' },
}

require("mini.surround").setup {
  custom_surroundings = {
    d = { input = catchall },
    r = { input = catchall },
  },
}

For brackets, quotes, and similar known in advance pairs it is fairly straightforward. Something beyond that - probably not and/or requires black magic coding. And I am not sure accounting for that use case specifically will be added to 'mini.surround'.

I can understand that, of course. I believe something like the above works well and clearly it should be a user configuration and not built-in.

I believe I'm getting this configured quite close to what I am used to, which is neat.

To be honest, I find the specification surroundings and the search algorithm to be slightly hard to understand, but now I've spent some time and it seems very well thought out!

[echasnovski]

To be honest, I find the specification surroundings and the search algorithm to be slightly hard to understand, but now I've spent some time and it seems very well thought out!

You're not the only one. I documented with many details because I often too forget how it works 😅 If done today, probably it would have been more modular and hopefully easier to understand.

[lervag]

No problem; I like the plugin. Thanks for creating and maintaining it! 🥰