Consider adding additional maintainers for the project

[akinsho]

Hi @folke

I'm not sure if you'll get this 😅 but I'm guessing you don't have much time to maintain this project any more, which is very understandable ❤️.

Which key is an excellent plugin which I think is very highly valued in the nvim ecosystem (at least that's how I feel). I recently tried living without it, and it was unbearable, my memory is not good enough any more. I've gotten too used to this plugin 😆. Anyway, would you be willing to add additional maintainers to the project (anyone who you pick or potential volunteer on this issue) to at least merge bugfixes etc. just to keep it functional.

For anyone reading this, if @folke is on board, please comment if you're interested. I personally have a bit too much on my plate with my own plugins and side projects. But if absolutely no one else will, then I'd be fine to merge a few crucial bugfixes (but won't be doing any features).

[folke]

Hi! I would definitely be interested in additional maintainers (for this and my other plugins).

I have about 10 plugins right now, and am thinking to setup an org and move all plugins inside of it. Or would it be best to just add maintainers per plugin? Wdyt?

[akinsho]

I think an org is good, there's actually nvim-lua which houses quite a few plugins. I think mostly TJs not sure if that's a good spot or just your own. Re individual vs org I think that's a personal choice. Org will be easier from a managing contributors perspective I guess

[max397574]

I could help with some things if you don't have time I don't have that much time rn as well but it will get much better in a month

I'm also already used to the sourcecode of this plugin a lil bit since I maintained a fork.

[MunifTanjim]

Any updates on this? Just allowing someone to merge small bugfixes would be very appreciated.

[folke]

@MunifTanjim Yes, I did look at your PR. The reason I did not merge it yet is that it is not a small bugfix.

Defaulting "replace_keycodes" to true is a breaking change and it will break people's existing keymaps, including my own. That's probably the same reason, why replace_keycodes is not true by default for nvim_set_keymap.

replace_keycodes is also not available in older Neovim versions.

Additionally I did a big rework of the DSL to make it much easier to create mappings where you can use opts anywhere, use additional lists to specify multiple mappings for the same node and a new cond key that enables/disables a ampping based on a value/function. I'll add in a better way to make configure replace_keycodes as the default as well.

Those changes are incoming very soon :)

Preview: