Olaf Dabrunz wrote:
> Example:
>
> :let l = ['a', 'b', 3]
> :lockvar 1 l
> :let l += ['x']
> E741: Value is locked: l
> :let l
> l ['a', 'b', 3, 'x']
>
> When the error message is shown, the list has already been changed.
>
>
> Changing lists in the v: scope has a related problem: v:oldfiles is not
> locked nor readonly and thus modifiable (as documented in
> ':he v:oldfiles'), but changing such a v: scope list variable prints an
> error message and does not succeed, except when extending it with '+=':
>
> :let v:oldfiles += ['test']
> E685: Internal error: set_var()
> :let v:oldfiles
> v:oldfiles ['fileA', 'fileB', ..., 'test']
>
> :let v:oldfiles = ['otherfile']
> E685: Internal error: set_var()
> :let v:oldfiles
> v:oldfiles ['fileA', 'fileB', ..., 'test']
>
>
> The patch adds checks for the lock and readonly flags of a variable
> before preparing a [+-.]= assignment, as that preparation alone is
> sufficient to extend an existing list variable. (Preparations for other
> variable types do not change existing variables.)
>
> The patch also adds code to allow v: scope lists, dicts, floats and
> funcrefs to be changed, unless they are locked or readonly or unless the
> change also would change the variable type.
>
> So far, this only affects v:oldfiles.
>
> v:key is either set to a string or a number and is readonly, v:val
> can have any type but is readonly, and the remaining v: scope
> variables have types fixed at string or number, and most are
> readonly as well.
>
> With these changes in place, a '+=' extension of a list, once prepared,
> cannot be canceled by any of the subsequent checks in set_var() before
> the variable setting is finalized. These checks are:
>
> - Check for user lock and readonly flags. Same as done in tv_op().
>
> - Two checks for variable type mismatches.
>
> For a list extension, tv_op() would have failed on a type mismatch
> already, and for others the assignment target variable has not been
> changed yet, so there is no problem if the assignment fails here.
>
> Note that in other places tv_op() is used to change the target value(s)
> directly, and no subsequent checks are done that could cause problems.
>
>
> A remaining problem is that the interdependence of the checks and
> preparations in set_var_lval() and tv_op() with checks in set_var()
> is implicit, and this makes this code more difficult to maintain. One
> could consider moving the tv_op() for setting plain variables into
> set_var(), but I have not looked into this sufficiently.
Thanks for the analysis, patch and test!
--
For large projects, Team Leaders use sophisticated project management software
to keep track of who's doing what. The software collects the lies and guesses
of the project team and organizes them in to instantly outdated charts that
are too boring to look at closely. This is called "planning".
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- [email protected] -- 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 ///
--
--
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].
For more options, visit https://groups.google.com/d/optout.
