propsal: Make "v:" prefix mandatory in scriptversion 2#4274
propsal: Make "v:" prefix mandatory in scriptversion 2#4274k-takata wants to merge 2 commits intovim:masterfrom
Conversation
"version" cannot be used as "v:version" in scriptversion 2 anymore. It can be used as a normal variable.
Codecov Report
@@ Coverage Diff @@
## master #4274 +/- ##
==========================================
+ Coverage 79.76% 79.8% +0.04%
==========================================
Files 106 106
Lines 141579 141576 -3
==========================================
+ Hits 112926 112982 +56
+ Misses 28653 28594 -59
Continue to review full report at Codecov.
|
|
With this patch, "version" cannot be used as "v:version" in scriptversion 2 anymore.
It can be used as a normal variable. (Same for "v:count" and other "v:" variables.)
What do you think?
We should increment scriptversion to 3 for this. Otherwise it's not
clear if the Vim that supports scriptversion 2 also has this
functionality. I don't think there is a drawback.
I see the patch actually does this for all the v: variables that can be
used without the v: prefix. I often accidentally use "count", thus I
like that.
…--
DINGO: You must spank her well and after you have spanked her you
may deal with her as you like and then ... spank me.
AMAZING: And spank me!
STUNNER: And me.
LOVELY: And me.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
Do you consider that the specification of scriptversion 2 has been already fixed? |
|
Do you consider that the specification of scriptversion 2 has been already fixed?
I thought that we haven't released Vim 8.2 yet, so the specification could be still changed.
We can still use `has('patch-8.1.xxxx')` to check if the v: prefix is mandatory or not.
Well, what is the drawback of using scriptversion 3?
…--
You cannot propel yourself forward by patting yourself on the back.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Maybe, no. |
|
Excuse the intrusion, but I think there is a drawback in letting the I hope you can make some sense of what I'm saying. I think it would be more reasonable to aggregate more changes in a single |
|
I think there's also the issue that every single script version currently has to be supported by the Vim codebase, as we will start seeing Vim plugins written with different script version expectations. The more distinct script versions the codebase accrue, the more possible code paths Vim will have to maintain till eternity with different avenues for potential bugs. |
|
I suppose that the idea is to deprecate old-style syntax, and then, maybe 20 years from now ;-) stop supporting it. To alleviate a little the task of plugin authors concerning various "script versions", I suggest that has('scriptversion') with no suffix be marked as reserved (i.e. not to be used) until or unless pre-scriptversion-1 syntax ceases to be supported. That way, A positive feature name can of course not be defined for that purpose, since Vim 7 and earlier would never recognise it. Best regards, |
|
There was no reason to jump to 3, and the OP seemed to admit that. |
|
I think there's also the issue that every single script version
currently has to be supported by the Vim codebase, as we will start
seeing Vim plugins written with different script version expectations.
The more distinct script versions the codebase accrue, the more
possible code paths Vim will have to maintain till eternity with
different avenues for potential bugs.
Having to support both behaviors for a long time is unavoidable, since
these are backwards incompatible changes. The only alternative is to
not make these changes, which means that "count" can never ever be used
as a local variable and .5 cannot be used for a floating point number.
It's unlikely to lead to bugs, since we add tests at the same time as
introducing the new feature.
…--
Not too long ago, compress was something you did to garbage...
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
Excuse the intrusion, but I think there is a drawback in letting the
`scriptversion` number progress too fast. It would become little
different from practices as `has('patch_x')`, where there are so many
that one should research at which patch level feature x has been
implemented and it's a nightmare from my point of view. If there are
too many `scriptversion` numbers, one would be tempted to just use the
latest one to be sure, instead of checking which one is the minimum
required, thus making the latest vim version a requirement. But I
think few people would do that, because most people that write plugins
don't want to enforce the use of last vim version, nor write the same
code 3-4 times to take into account different `scriptversion`'s.
It's actually a lot simpler if the scriptversion is incremented for
every feature (or dropped feature), so that there is a one-to-one
relation.
Assuming that the new feature is useful, some users will quickly start
using it, and if then changing the meaning of the scriptversion we will
annoy these early adopters. There is too much time between minor
releases.
I hope you can make some sense of what I'm saying. I think it would be
more reasonable to aggregate more changes in a single `scriptversion`
revision. It would then be much easier to say `vim 8.2` or `vim 8.3`
is required. Otherwise this could just add up to the `has('patch_x')`
nightmare.
It's not, since the scriptversion has to be stated in the script, not
just around some lines. Checking the version is mostly pointless, since
you would then need to support both the old and new version. Might as
well just do the old one then. Unless we add a new, incompatible
version that is only available with a certain scriptversion. I don't
expect that will happen, I don't see something where this would apply.
…--
LAUNCELOT: At last! A call! A cry of distress ...
(he draws his sword, and turns to CONCORDE)
Concorde! Brave, Concorde ... you shall not have died in vain!
CONCORDE: I'm not quite dead, sir ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Not all Vim variables require the v: prefix.
Solution: When scriptversion is 3 all Vim variables can only be used with
the v: prefix. (Ken Takata, closes vim/vim#4274)
vim/vim@d2e716e
Include scriptversion-3 section in eval.txt from
vim/vim@911ead1.
Problem: Cannot enforce a Vim script style. Solution: Add the :scriptversion command. (closes vim/vim#3857) vim/vim@558ca4a :scriptversion is N/A, but ":let ..=" is relevant. N/A patches for version.c vim-patch:8.1.1188: not all Vim variables require the v: prefix Problem: Not all Vim variables require the v: prefix. Solution: When scriptversion is 3 all Vim variables can only be used with the v: prefix. (Ken Takata, closes vim/vim#4274) vim/vim@d2e716e vim-patch:8.1.1190: has('vimscript-3') does not work Problem: has('vimscript-3') does not work. Solution: Add "vimscript-3" to the list of features. vim/vim@93a4879 vim-patch:8.1.2038: has('vimscript-4') is always 0 Problem: has('vimscript-4') is always 0. Solution: Add "vimscript-4" to the feature table. (Naruhiko Nishino, closes vim/vim#4941) vim/vim@af91438 vim-patch:8.1.2043: not sufficient testing for quoted numbers Problem: Not sufficient testing for quoted numbers. Solution: Add a few more test cases. vim/vim@ea8dcf8
Problem: Cannot enforce a Vim script style. Solution: Add the :scriptversion command. (closes vim/vim#3857) vim/vim@558ca4a :scriptversion is N/A, but ":let ..=" is relevant. N/A patches for version.c vim-patch:8.1.1188: not all Vim variables require the v: prefix Problem: Not all Vim variables require the v: prefix. Solution: When scriptversion is 3 all Vim variables can only be used with the v: prefix. (Ken Takata, closes vim/vim#4274) vim/vim@d2e716e vim-patch:8.1.1190: has('vimscript-3') does not work Problem: has('vimscript-3') does not work. Solution: Add "vimscript-3" to the list of features. vim/vim@93a4879 vim-patch:8.1.2038: has('vimscript-4') is always 0 Problem: has('vimscript-4') is always 0. Solution: Add "vimscript-4" to the feature table. (Naruhiko Nishino, closes vim/vim#4941) vim/vim@af91438
Problem: Cannot enforce a Vim script style. Solution: Add the :scriptversion command. (closes vim/vim#3857) vim/vim@558ca4a :scriptversion is N/A, but ":let ..=" is relevant. N/A patches for version.c vim-patch:8.1.1188: not all Vim variables require the v: prefix Problem: Not all Vim variables require the v: prefix. Solution: When scriptversion is 3 all Vim variables can only be used with the v: prefix. (Ken Takata, closes vim/vim#4274) vim/vim@d2e716e vim-patch:8.1.1190: has('vimscript-3') does not work Problem: has('vimscript-3') does not work. Solution: Add "vimscript-3" to the list of features. vim/vim@93a4879 vim-patch:8.1.2038: has('vimscript-4') is always 0 Problem: has('vimscript-4') is always 0. Solution: Add "vimscript-4" to the feature table. (Naruhiko Nishino, closes vim/vim#4941) vim/vim@af91438
With this patch, "version" cannot be used as "v:version" in scriptversion 2 anymore.
It can be used as a normal variable. (Same for "v:count" and other "v:" variables.)
What do you think?