Provide <Plug> mappings for vim legacy users

[saccarosium]

I use vim 9 but with a legacy vimrc, for compatibility reasons, and I'm not really hable to use this plugin (at least that I know of).

If you don't know what mappings are checkout :h <Plug> and :h using-<Plug>.

[girishji]

Can you try scope#fuzzy#File(), scope#fuzzy#Grep() instead? It should autoload.

[girishji]

Maybe <plug> is still better, especially if it goes hunting for scope/fuzzy.vim in autoload directories (available in VIMRELTIME) every time key is invoked. I don't know how legacy script works, whether it caches symbols resolved through autoload mechanism.

[saccarosium]

As far as I know the performance is the same.

<Plug> is the better approach because it is the way, developed by the vim developer for plugins, to expose actions and functionality to the user. There is little or no gain to simply not use an interface that does the job and that work consistently across legacy and vim9 vimscript.

Isn't this much nicer?

vim9script

# Defined by the plugin
nnoremap <Plug>(ScopeKeymap) <scriptcmd>scope#fuzzy#Keymap()<CR>

# User configuration
nnoremap <leader>f <Plug>(ScopeKeymap)

The advantages are:

• works across vimscript versions without modification
• Much nicer to remember for the user
• If one day you want to change where the function is located, you can do it safely without woring breaking people setup
• You can still call the function manually if you want to

I think we should not make the same mistake made by the neovim plugin authors that stopped using <plug> and come up with their own way to deal with the problem. This goes also to the Setup function but this is another topic.

[girishji]

We want to allow user to pass arguments to functions. They may prefer rg with specific flags instead of the default grep in fuzzy.Grep(). In case of find I have multiple key mappings (to search Vim src files, my .vim dir, etc.). How to deal with that since <Plug> does not take arguments (if I remember correctly)?

[saccarosium]

We want to allow user to pass arguments to functions.

I see... This is probably not for me than. But I would suggest to do two things.

Document how to use the plugin from legacy vimscript (at least the simple stuff like this nnoremap <yourkey> <scriptcmd>vim9cmd scope#fuzzy#Keymap()<CR>)

I think it is a better idea to provide the main functions in a "scope" below. scope#Keymap() rather than scope#fuzzy#Keymap(). You can achieve this by simply have a structure like this:

autoload/
| scope/ <- directory
| scope.vim <- file

Thanks for the support

[girishji]

Thanks for suggestions.

[girishji]

I think creating a bunch of commands (that can also be key-mapped) may work out better for legacy script users. Commands can take arguments, and can have custom completion.

Also, I think putting scope.vim directly inside autoload will create conflict if user has .vim/autoload/scope.vim, and decides to do import autoload 'scope.vim'. In legacy script function names can be qualified with # like function scope#Keymap(), but it does not work for def in vim9script.

[saccarosium]

Also, I think putting scope.vim directly inside autoload will create conflict if user has >.vim/autoload/scope.vim, and decides to do import autoload 'scope.vim'. In legacy script >function names can be qualified with # like function scope#Keymap(), but it does not work for def in vim9script.

After some testing here is what I found.

autoload/
| scope/ <- directory
| scope.vim <- file

If you do this and the user has a script named scope in their autoload dir the plugin will be shadowed. So yea this is not a good idea. I've mentioned it because it is the pattern used in legacy plugins. I guess this is not applicable anymore.

I think creating a bunch of commands (that can also be key-mapped) may work out better for legacy script users. Commands can take arguments, and can have custom completion.

Yes, this is the way to go, in my opinion.

[girishji]

If you do this and the user has a script named scope in their autoload dir the plugin will be shadowed.

This is expected since plugins are loaded first, and then user's .vim. Even though autoload is lazy loading, it actually gets the symbol names up front from the script, so order matters.

[girishji]

Added the commands, see README. :Scope <tab>.