Hi,

Thanks for trying out the patch and the detailed report. See below for some
comments.

On Sat, Aug 21, 2021 at 9:48 AM lacygoill <[email protected]> wrote:

> This could be handy for when the opfunc is a script-local function. We
> can't write this:
>
> set operatorfunc=s:MyOpfunc
>
> Because it raises E120:
>
> E120: Using <SID> not in a script context: s:MyOpfunc
>
> So, we have to write this:
>
> let &operatorfunc = expand('<SID>') .. 'MyOpfunc'
>
> Which looks a bit weird.
>
> But with a lambda, we could write this instead:
>
> set operatorfunc={type\ ->\ s:MyOpfunc(type)}
>
> One could argue that it still looks weird. I still prefer reading a lambda
> which can be used in many other contexts, rather than expand('<SID>'),
> which is less often used.
> ------------------------------
>
> Just 2 remarks. It works with :set but not with :let. That is, we cannot
> write this:
>
> let &operatorfunc = {type -> s:MyOpfunc(type)}
>
> Because it raises E729:
>
> E729: Using a Funcref as a String
>
> It still doesn't work if we manually coerce the lambda into a string:
>

Yes. Currently this option only supports a string value. So to set the
option using 'let' you need to quote the lambda:

let &operatorfunc = '{type -> s:MyOpfunc(type)}'


> let &operatorfunc = {type -> s:MyOpfunc(type)}->string()
>                                               ^--------^
>
> Because this time, it raises E129:
>
> E129: Function name required
>
> It would be nice if could work so that we don't have to escape spaces:
>
> # ugly
> set operatorfunc={type\ ->\ s:MyOpfunc(type)}
>                       ^   ^
>
> # nicer
> let &operatorfunc = {type -> s:MyOpfunc(type)}
>                          ^  ^
>
>
Agreed. But supporting this syntax is a lot more work. We need
to add a new option type that can accept function names (string)
or lambdas or funcrefs.


> Also, it doesn't work with a Vim9 lambda. That is, in a Vim9
> script/function, we cannot write this:
>
> set operatorfunc=(type)\ =>\ MyOpfunc(type)
>
>
Yes. I will take a look at this.


> Because it raises E117:
>
> E117: Unknown function: (type) => MyOpfunc(type)
>
> I suspect that's because the option is wrongly evaluated in the legacy
> context. Possibly relevant todo item:
>
> Use the location where the option was set for deciding whether it's to be
> evaluated in Vim9 script context.
>
> As a workaround, we have to use the :legacy modifier:
>
> legacy set operatorfunc={type\ ->\ MyOpfunc(type)}
> ^----^
>
> Using the example given at :help g@:
>

Thanks for enhancing the example with the new syntax.

Regards,
Yegappan


> vim9scriptnnoremap <expr> <F4> <SID>CountSpaces()xnoremap <expr> <F4> 
> <SID>CountSpaces()nnoremap <expr> <F4><F4> <SID>CountSpaces() .. '_'
> def CountSpaces(type = ''): string
>   if type == ''
>     legacy set operatorfunc={type\ ->\ CountSpaces(type)}
>     return 'g@'
>   endif
>
>   var sel_save: string = &selection
>   var reg_save: dict<any> = getreginfo('"')
>   var cb_save: string = &clipboard
>   var visual_marks_save: list<list<number>> = [getpos("'<"), getpos("'>")]
>
>   try
>     set clipboard= selection=inclusive
>     var commands: dict<string> = {line: "'[V']y", char: "`[v`]y", block: 
> "`[\<c-v>`]y"}
>     silent execute 'noautocmd keepjumps normal! ' .. get(commands, type, '"')
>     echom getreg('"')->count(' ')
>   finally
>     setreg('"', reg_save)
>     setpos("'<", visual_marks_save[0])
>     setpos("'>", visual_marks_save[1])
>     &clipboard = cb_save
>     &selection = sel_save
>   endtry
>   return ''enddef
> 'a b c d e'->setline(1)feedkeys("\<F4>\<F4>")
>
> What's weird is that we don't have to specify the s: prefix in the legacy
> lambda in front of the script-local function name. Usually, in the legacy
> context, s: is mandatory; it can only be dropped in the Vim9 context.
>
>
>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAW7x7kmD47XoskeG7dLFahsaVq2jitokbamG51Bb%3DLOWF%2BAvQ%40mail.gmail.com.

Raspunde prin e-mail lui