search

echasnovski / mini.nvim

Library of 40+ independent Lua modules improving overall Neovim (version 0.8 and higher) experience with minimal effort
MIT License
4.47k stars 175 forks source link

Expose the rest of `H.builtin_textobjects` so users can assign them to a different key #893

Closed IndianBoy42 closed 1 month ago

IndianBoy42 commented 1 month ago

Contributing guidelines

Module(s)

mini.ai

Description

As someone who doesn't do much HTML but does rust, id rather have it/at as an alias for i>/a>, and perhaps keep the HTML tag behaviour under iT,aT. I have a few other similar rearrangements to the textobjects.

Right now I've implemented in by pasting the spec from mini.ai into my custom_textobjects, but it would be nicer if the builtins were exposed under ai.gen_spec (like argument and function_call)

echasnovski commented 1 month ago

Thanks for the suggestion!

The "argument" and "function_call" textobjects are exposed in gen_spec because they might be configured to use some different hyper parameters.

Currently I don't think exposing the whole 'builtin_textobjects' is a good idea from maintenance perspective while bringing not huge amount of dividends (setting them up explicitly still works). But I'll think about it.

echasnovski commented 1 month ago

Sorry, I don't think it is too much for users to have explicit definitions for textobjects that they want to use. And as already was said, "argument" and "function_call" may need configuration so having them in gen_spec makes sense.

Closing as not planned.

IndianBoy42 commented 1 month ago

That's disappointing to hear, maybe i lack perspective but I didn't think that there would be such a maintenance burden from exposing whats already implemented. I just want to use the existing builtin textobjects with a different key; now I have to repeat the esoteric definitions and lose out on updates unless I manually check whether they have changed.

echasnovski commented 1 month ago

... but I didn't think that there would be such a maintenance burden from exposing whats already implemented.

It is implemented as an internal helper right now which means that it is free to be transformed in any way that might be necessary. Exporting it makes it harder to do.

Plus documenting and testing all of those 15 extra specifications takes space and effort.

Plus if this is done in 'mini.ai', then it is reasonable to be done in 'mini.surround', which adds 13 more surrounding specifications to export, document, and test.

As both 'mini.ai' and 'mini.surround' are already quite big and benefits are not huge, I'd better not export them.