[vim/vim] :help vim9-scopes is outdated (Issue #9724)

29 views
Skip to first unread message

bfrg

unread,
Feb 8, 2022, 6:42:15 PM2/8/22
to vim/vim, Subscribed

Steps to reproduce

The section under :h vim9-scopes needs to be updated since it's no longer possible to write def scriptname#function(). Doing so gives the error:

E1263: cannot use name with # in Vim9 script, use export instead

What is the point of keeping the prefix s: for functions or variables? I personally don't see an advantage. Removing it (or forcing it) will make all plugins look more consistent. There is already an inconsistency in Vim's runtime. See for example s:LoadFTPlugin() and SetSyn(name: string).

And out of curiosity, why doesn't the file ftplugin.vim contain any vim9script declaration at the top of the file. The first few lines use the old legacy vimscript syntax, whereas the def function the new syntax. In my option, that's a little bit confusing. Why not just vim9script the entire script? Similar for menu.vim and synmenu.vim.

Expected behaviour

Version of Vim

8.2.4333

Environment

Linux

Logs and stack traces

No response


Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/9724@github.com>

Bram Moolenaar

unread,
Feb 9, 2022, 8:27:18 AM2/9/22
to vim/vim, Subscribed


> ### Steps to reproduce
>
> The section under `:h vim9-scopes` needs to be updated since it's no longer possible to write `def scriptname#function()`. Doing so gives the error:

> ```
> E1263: cannot use name with # in Vim9 script, use export instead
> ```

I'll fix that.


> What is the point of keeping the prefix `s:` for functions or
> variables? I personally don't see an advantage. Removing it (or
> forcing it) will make all plugins look more consistent.

Yes, we could drop it. The only reason I can think of to keep it is
that in a legacy function the s: prefix must be used:

vim9script

def Local()
echo 'local'
enddef

func Legacy()
call s:Local() " won't work without s:
endfunc

Legacy()


> There is
> already an inconsistency in Vim's runtime. See for example
> [`s:LoadFTPlugin()`](https://github.com/vim/vim/blob/b6a138eb334621f60c5891d035f80f398d59dbd3/runtime/ftplugin.vim#L15)
> and [`SetSyn(name:
> string)`](https://github.com/vim/vim/blob/3e79c97c18c50f97797ab13ed81c4011eba9aba0/runtime/synmenu.vim#L9).

This comes from converting a legacy script to Vim9. So the question is
whether it is good to force removing the "s:" prefix or is it more
convenient to let it there?


> And out of curiosity, why doesn't the file `ftplugin.vim` contain any
> `vim9script` declaration at the top of the file. The first few lines
> use the old legacy vimscript syntax, whereas the `def` function the
> new syntax. In my option, that's a little bit confusing. Why not just
> `vim9script` the entire script? Similar for `menu.vim` and
> `synmenu.vim`.

It's because of the "finish" command. I wasn't quite sure if
"vim9script noclear" would work. The "did_load_ftplugin" is cleared in
ftplugof.vim. But the function could remain. I'll see if I can make
that work.


--
How To Keep A Healthy Level Of Insanity:
8. Don't use any punctuation marks.

/// 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.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/9724/1033760122@github.com>

bfrg

unread,
Feb 9, 2022, 8:11:35 PM2/9/22
to vim/vim, Subscribed

Fixed in 9da17d7.


Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/9724/1034379152@github.com>

bfrg

unread,
Feb 9, 2022, 8:11:38 PM2/9/22
to vim/vim, Subscribed

Closed #9724.


Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/9724/issue_event/6038488482@github.com>

JohnBeckett

unread,
Feb 9, 2022, 8:53:48 PM2/9/22
to vim_dev
On Thursday, February 10, 2022 at 12:27:18 AM UTC+11 Bram Moolenaar wrote:

> This comes from converting a legacy script to Vim9. So the question is
> whether it is good to force removing the "s:" prefix or is it more
> convenient to let it there?

If s: is never needed in vim9script, it should be an error to include it. As someone learning to use the new system, I want firm guidance—should I include s: or not? If I see it in someone's script, I'm going to wonder if it should be in mine (perhaps there is a performance advantage or something else I don't know about). It wastes everyone's time if arcane syntax is sometimes used.

There will never be another opportunity to decide how vim9script should work.

John

Message ID: <vim/vim/issues/9724/1033760122@github.com>

Bram Moolenaar

unread,
Feb 10, 2022, 4:31:53 PM2/10/22
to vim...@googlegroups.com, JohnBeckett
It's definitely cleaner to just disallow using "s:" in any Vim9 script.
It fits in with not allowing defining script level items (functions and
variables) in a function.

It is required of the user to understand that functions without "s:" are
script-local, but was already the case anyway, since it could be left
out.

Let me look into it, see what would fail.

--
How To Keep A Healthy Level Of Insanity:
16. Have your coworkers address you by your wrestling name, Rock Hard Kim.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\

Bram Moolenaar

unread,
Feb 10, 2022, 5:31:11 PM2/10/22
to vim...@googlegroups.com, Bram Moolenaar, JohnBeckett

I wrote:

> John Beckett wrote:
>
> > On Thursday, February 10, 2022 at 12:27:18 AM UTC+11 Bram Moolenaar wrote:
> >
> > > This comes from converting a legacy script to Vim9. So the question is
> > > whether it is good to force removing the "s:" prefix or is it more
> > > convenient to let it there?
> >
> > If s: is never needed in vim9script, it should be an error to include it.
> > As someone learning to use the new system, I want firm guidance—should I
> > include s: or not? If I see it in someone's script, I'm going to wonder if
> > it should be in mine (perhaps there is a performance advantage or something
> > else I don't know about). It wastes everyone's time if arcane syntax is
> > sometimes used.
> >
> > There will never be another opportunity to decide how vim9script should
> > work.
>
> It's definitely cleaner to just disallow using "s:" in any Vim9 script.
> It fits in with not allowing defining script level items (functions and
> variables) in a function.
>
> It is required of the user to understand that functions without "s:" are
> script-local, but was already the case anyway, since it could be left
> out.
>
> Let me look into it, see what would fail.

One situation where we would still need to use "s:" is when a :def
function is used in a legacy script. There it is possible to create a
new script variable, and also :unlet it.

This is the opposite of using a legacy function in a Vim9 script, where
it is required to use the "s:" prefix to access script-local variables.
It is even possible to define new script-local variables. But :unlet
can't be used, which is inconsistent. We probably need to disallow
creating new script variables, they should be declared at the script
level.

--
How To Keep A Healthy Level Of Insanity:
17. When the money comes out the ATM, scream "I won!, I won! 3rd
time this week!!!!!"

Bram Moolenaar

unread,
Feb 11, 2022, 6:09:08 AM2/11/22
to Bram Moolenaar, vim...@googlegroups.com, JohnBeckett
This is what we would have then:

- Vim9 script at script level: "s:" NOT allowed.
- Vim9 script in :def function: "s:" NOT allowed.
- Vim9 script in legacy function: "s:" required for script items.
- legacy script at script level: "s:" required for script items.
- legacy script in :def function: "s:" required for script items that are not
defined yet, "s:" optional for existing script items.
- legacy script in legacy function: "s:" required for script items

Is this logical?

An alternative is to only disallow using "s:" in Vim9 script at the
script level, but still allow it in all functions. I believe that would
be the simplest rule.

So we have these choices:
- Leave as it is now, "s:" is optional everywhere
- Disallow "s:" in Vim9 script, only at the script level
- Disallow "s:" where it is not needed, as explained above


--
In many of the more relaxed civilizations on the Outer Eastern Rim of the
Galaxy, "The Hitchhiker's Guide to the Galaxy" has already supplanted the
great "Encyclopedia Galactica" as the standard repository of all knowledge
and wisdom, for though it has many omissions and contains much that is
apocryphal, or at least wildly inaccurate, it scores over the older, more
pedestrian work in two important respects.
First, it is slightly cheaper; and second, it has the words "DON'T PANIC"
inscribed in large friendly letters on its cover.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

JohnBeckett

unread,
Feb 12, 2022, 3:59:00 AM2/12/22
to vim_dev
On Friday, February 11, 2022 at 10:09:08 PM UTC+11 Bram Moolenaar wrote:
> This is what we would have then:
>
>  - Vim9 script at script level: "s:" NOT allowed.
>  - Vim9 script in :def function: "s:" NOT allowed.
>  - Vim9 script in legacy function: "s:" required for script items.
>  - legacy script at script level: "s:" required for script items.
>  - legacy script in :def function: "s:" required for script items that are not defined yet, "s:" optional for existing script items.
>  - legacy script in legacy function: "s:" required for script items

I am not familiar enough with the details to make a meaningful recommendation. However, the above list mentions "legacy" in the last four items and it would make sense for s: to be required/optional there. The first two items (Vim9 script at script level, Vim9 script in :def function) should not permit s:.

John
Reply all
Reply to author
Forward
0 new messages