[vim/vim] Allow assigning a Funcref to autoload variable (PR #11031)
thinca
In Vim, defining a User function that starts with a lowercase letter is not allowed because it could overwrite a built-in function.
However, defining an autoload function that starts with a lowercase letter is permitted because it does not cause the above problem.
For the same reason, Vim does not allow Funcref to be assigned to a global variable whose name begins with a lowercase letter.
This also applies to the autoload variable; let foo#tr = function('tr') is not allowed and must be let Foo#tr = function('tr').
I see no need for this restriction. let foo#tr = function('tr') should be allowed.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/11031
Commit Summary
- 9e95088 Allow assigning a Funcref to autoload variable
File Changes
(2 files)
- M src/evalvars.c (4)
- M src/testdir/test_let.vim (4)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #11031 (9e95088) into master (be807d5) will decrease coverage by
82.17%.
The diff coverage is0.00%.
@@ Coverage Diff @@ ## master #11031 +/- ## =========================================== - Coverage 82.47% 0.29% -82.18% =========================================== Files 152 152 Lines 177682 173438 -4244 Branches 40341 39918 -423 =========================================== - Hits 146539 520 -146019 - Misses 18948 172861 +153913 + Partials 12195 57 -12138
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | ? |
|
| huge-gcc-none | ? |
|
| huge-gcc-testgui | ? |
|
| huge-gcc-unittests | 0.29% <0.00%> (ø) |
|
| linux | 0.29% <0.00%> (-82.18%) |
⬇️ |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/evalvars.c | 0.00% <0.00%> (-91.31%) |
⬇️ |
| src/float.c | 0.00% <0.00%> (-98.44%) |
⬇️ |
| src/sha256.c | 0.00% <0.00%> (-94.90%) |
⬇️ |
| src/gui_gtk_f.c | 0.00% <0.00%> (-94.72%) |
⬇️ |
| src/arabic.c | 0.00% <0.00%> (-94.57%) |
⬇️ |
| src/crypt_zip.c | 0.00% <0.00%> (-94.12%) |
⬇️ |
| src/typval.c | 0.00% <0.00%> (-92.47%) |
⬇️ |
| src/debugger.c | 0.00% <0.00%> (-92.23%) |
⬇️ |
| src/blob.c | 0.00% <0.00%> (-92.21%) |
⬇️ |
| src/vim9compile.c | 0.00% <0.00%> (-91.85%) |
⬇️ |
| ... and 137 more |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> In Vim, defining a User function that starts with a lowercase letter
> is not allowed because it could overwrite a built-in function.
> However, defining an autoload function that starts with a lowercase
> letter is permitted because it does not cause the above problem.
>
> For the same reason, Vim does not allow Funcref to be assigned to a
> global variable whose name begins with a lowercase letter.
> This also applies to the autoload variable; `let foo#tr =
> function('tr')`.
> I see no need for this restriction. `let foo#tr =
Well, not when used with the "name#" prefix. But inside the autoload
script it can be used without the prefix, which does cause shadowing a
builtin function.
Thus when you, like in the test, do:
let foo#tr = function('tr')
problem. At least in Vim9 script, where the "s:" prefix is not used.
Right?
--
This computer is so slow, it takes forever to execute and endless loop!
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
thinca
In legacy Vim script, name# prefix is always necessary.
" autoload/name.vim echo foo " This is g:foo, not name#foo echo s:foo " This is s:foo, not name#foo function name#func() echo foo " This is l:foo, not name#foo endfunction
In Vim9 script, as you say, exported variable is an autoload variable and can be access without prefix.
But there is no problem.
vim9script # autoload/name.vim # This occurs an error "E704: Funcref variable name must start with a capital: tr" export var tr = () => 'tr'
vim9script # autoload/name.vim # This variable can rewrite by `let name#tr = { -> 'tr' }` from outside of script with this patch. export var tr = '' def Foo() # But this `tr()` is always built-in function. Vim9 script is compiled first. echo tr('foo', 'o', 'a') enddef
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> In legacy Vim script, `name#` prefix is always necessary.
>
> " autoload/name.vim
>
> echo foo " This is g:foo, not name#foo
> echo s:foo " This is s:foo, not name#foo
>
> function name#func()
> echo foo " This is l:foo, not name#foo
> endfunction
OK, and it actually checks if the name of the script starts with a
capital, not the variable itself, so that is pointless.
> In Vim9 script, as you say, exported variable is an autoload variable
> and can be access without prefix.
> But there is no problem.
>
> vim9script
> # autoload/name.vim
>
> # This occurs an error "E704: Funcref variable name must start with a capital: tr"
> export var tr = () => 'tr'
>
> ```vim
> vim9script
> # autoload/name.vim
>
> # This variable can rewrite by `let name#tr = { -> 'tr' }` from outside of script with this patch.
> export var tr = ''
>
> def Foo()
> # But this `tr()` is always built-in function. Vim9 script is compiled first.
> echo tr('foo', 'o', 'a')
> enddef
Hmm, I cannot think of a way to go around this, assigning a variable
outside of a Vim9 script can be expected to always fail.
--
BEDEVERE: Wait. Wait ... tell me, what also floats on water?
ALL: Bread? No, no, no. Apples .... gravy ... very small rocks ...
ARTHUR: A duck.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.