[Feature]: per-mode implementations for functions (funcs)

[hinell]

Similar Issues

• Before filing, I have searched for similar issues.

Description

Very similiar to, but for functions:

• [Feature]: per-mode implementations for commands #215

Can we have the same feature for legendary.funcs(...)?

There are functions, that can only be run in visual mode, so it's logical to have { mode = {...} } restrictions so upon running :Legendary we have these funcs filtered...

endary.funcs({
	{ mode = { "v" }, description = "Buffer: my fn in visual mode" , fn }
})

[mrjones2014]

Sounds good. Should be pretty easy to implement.

[mrjones2014]

@hinell are you willing to submit a PR for this? If not I can probably get to it next week.

[hinell]

We need an alternative to legendary.nvim; this project along with some others isn't contribution-friendly; please notify me if you want to unite an effort in replacing it.

[mrjones2014]

This project is definitely contribution friendly! For context for everyone else reading, @hinell made a PR, I requested some changes, and he refused to make them. I'm under no obligation to merge an incomplete PR just because you say so. Here's the PR in question: #415

Anyone else is more than welcome to pick up the PR and actually implement the very simple changes I requested in order to make the feature align with the existing API for other item types 🙂

EDIT: I can't figure out how to filter out github-actions PRs, but here's the list with mine excluded: https://github.com/mrjones2014/legendary.nvim/pulls?q=is%3Apr+-author%3Amrjones2014

You can see that even @hinell himself has had PRs merged 🙂

[hinell]

The problem is that @mrjones2014 have suggested (very vaguely) me to implement entire keymaps-like mode= api in my #415 PR when it was never intended to do so; I suggested and suggest to do that himself as he knows better what he wants, not me. This issue might be safely closed when #415 is merged, cause what is implemented out there is enough to respect nvim editor modes when functions are run. Cheers.

[mrjones2014]

entire keymaps-like mode= api

Not sure what you mean. All I was saying is if we're supporting modes, like we do with keymaps, then we should support the same item definition syntax. Seems like a pretty simple ask to me.