-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom provider: allow entering value not in list #459
Comments
Well, you can centainly do that in |
I don't understand how it's possible to do that. Eg below is an example of clap configured with: let clap_provider_todoist = {
\ 'source': {-> Todoist__listProjects()},
\ 'sink': 'Todoist',
\} When hitting CR in this case, it would be nice that |
I misunderstand your initial question. See how vim-clap/autoload/clap/provider/filer.vim Line 254 in ee02a6f
vim-clap/autoload/clap/provider/filer.vim Lines 220 to 222 in ee02a6f
|
Is Also do you think #417 is getting merged, and if so will it be possible to extend it to custom providers? |
#417 seems stalled. What's more, each builtin provider in the clap repo is essentially a custom provider, you can implement your own provider like all the builtin providers. |
Got it. And would it be possible to add a boolean option to simply pass the argument even if it's not in the list? |
I can't understand this design. If you have a good reason, please elaborate. What's the use case, how people can use it, like the current various hooks of clap. |
It's much easier to have a boolean option to allow passing non-listed values than to have to implement a function for each different providers. It becomes repetitive very quickly. For example, in my config I have 2 providers that would benefit from it: Here is an example with my proposition: let clap_provider_note = {
\ 'source': {-> xolox#notes#cmd_complete('', 'Note ', 0)},
\ 'sink': 'Note',
\ 'allow_non_listed': v:true,
\}
let clap_provider_todoist = {
\ 'source': {-> Todoist__listProjects()},
\ 'sink': 'Todoist',
\ 'allow_non_listed': v:true,
\} Here it is with the current options: function! s:note_on_no_matches (v)
execute 'Note' a:v
endfunc
let clap_provider_note = {
\ 'source': {-> xolox#notes#cmd_complete('', 'Note ', 0)},
\ 'sink': 'Note',
\ 'source_type': g:__t_rpc,
\ 'on_no_matches': function('s:note_on_no_matches'),
\}
function! s:todoist_on_no_matches (v)
execute 'Todoist' a:v
endfunc
let clap_provider_todoist = {
\ 'source': {-> Todoist__listProjects()},
\ 'sink': 'Todoist',
\ 'source_type': g:__t_rpc,
\ 'on_no_matches': function('s:todoist_on_no_matches'),
\} Very repetitive and much harder to understand (also doesn't work, not sure why). Clap is wonderful because it can be a generic option picker, which is something that lacks in vim. But to be usable, it needs to expose an API that is sensible and that covers the most common use-cases. This is a use-case that I believe is quite common. |
What if I want to do another thing in And you can simplify your example with lambda if you are not happy with defining the functions: let clap_provider_note = {
\ 'source': {-> xolox#notes#cmd_complete('', 'Note ', 0)},
\ 'sink': 'Note',
\ 'on_no_matches': { input -> execute('Note '.input)},
\} |
I think it's a common enough use-case that it should be implemented as a boolean option. Also the boolean option is important for rendering. Sure
(or I think the filer PR had something like This way, the user clearly understands that they have the possibility to call the command with an unexistent entry. Right now, there is a NO MATCHES FOUND message which doesn't imply the option to call an unexistent entry. |
I can consider it if someone sends a good patch with a reasonable design. Each entry relates to the |
Stale issue message |
It would be nice to add an option to allow entering a value not in the source for user-defined providers.
Use case: in todoist.nvim, the user can
:Todoist project-name
and unexistent projects are created.The text was updated successfully, but these errors were encountered: