Custom provider: allow entering value not in list

[romgrk]

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.

[liuchengxu]

Well, you can centainly do that in source() function. Firstly, you need to store project-name somewhere so that the provider can use it. And you check if project-name exists in source(), if the project doesn't exist, create a new one. All happens in source() of your provider.

[romgrk]

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 :Todoist be called even if new-project doesn't exist in the list. Currently, it doesn't seem to be possible. If it is, could you provide more details?

[liuchengxu]

I misunderstand your initial question. See how filer handles the case of no matches found.

vim-clap/autoload/clap/provider/filer.vim

Line 254 in ee02a6f

let s:filer.on_no_matches = function('s:filer_on_no_matches')

vim-clap/autoload/clap/provider/filer.vim

Lines 220 to 222 in ee02a6f

	function! s:filer_on_no_matches(input) abort
	execute 'edit' a:input
	endfunction

[romgrk]

Is on_no_matches available for custom providers? I don't see it in the documentation.

Also do you think #417 is getting merged, and if so will it be possible to extend it to custom providers?

[liuchengxu]

on_no_matches is mentioned in https://github.com/liuchengxu/vim-clap/blob/master/PROVIDER.md#rpc-based, but it's also usable for the regular providers. The docs need update.

#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.

[romgrk]

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?

[liuchengxu]

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.

[romgrk]

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.

[liuchengxu]

What if I want to do another thing in on_no_matches which is different with what sink does?

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)},
\}

[romgrk]

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 on_no_matches tells that there is a custom behavior, whatever it might be. But allow_non_listed makes it possible to render the new entry in the list with a marker, eg:

╭───────────────────────────────────────────────────╮
│provider> example                                  │
├───────────────────────────────────────────────────┤
│example1                                           │
│example2                                           │
│example (new entry)                                │
╰───────────────────────────────────────────────────╯

(or I think the filer PR had something like [+], but anyway it's the same idea)

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.

[liuchengxu]

I can consider it if someone sends a good patch with a reasonable design. Each entry relates to the sink function by default, adding new entries means these also must have a related sink-like hook function to be executed when they are selected/picked.

[github-actions]

Stale issue message