> > Nikolai Pavlov wrote:
> >
> >> @brammool This is not fine. First, this shows yet another
> >> inconsistency between different notations. Second, dictionary with
> >> variables in not guaranteed to be `b:` and `let d = b:|call
> >> islocked('d.changedtick')` errors out just in the same fashion. E.g.
> >> consider writing a serializer which saves containers with locked
> >> status and it is unable to serialize b: (such thing may be useful for
> >> debugging: `:let b:` is not showing locked status). Third, ***I am not
> >> changing a variable***. If `islocked()` attempts or it seems like
> >> `islocked()` may attempt changing a variable this looks very strange
> >> and makes function very suspicious. Fourth, there is an existing key,
> >> syntactically correct and valid expression (which may even be used to
> >> obtain `count`) and it still errors out.
> >
> > OK, islocked('d.changedtick') is something that should work.
> >
> > I never intended b:.changedtick to be a valid syntax. It's ugly.
> > I suppose we can't make that an error now, for backwards compability.
>
> It is a direct consequence of existence of `b:` scope dictionary
> variable and short form of dictionary indexing syntax, making it not
> work would be inconsistent and not only incompatible. I sometimes use
> things like `funccall(args).key`.
I was talking about the syntax, not the semantics. Although b: behaves
like a dictionary, it's a namespace in which members are accessed
directly, without a separating ".".
> >> By the way, why `islocked('v:count')` is zero and there are no
> >> functions like `isfixed()`?
> >
> > Been like that forever. v:count is read-only, and there is no
> > isreadonly().
> >
> > We can probably remove the locked flag on b:changedtick, for
> > consistency.
>
> I intentionally added it there because `islocked('b:changedtick')`
> intentionally returned 1, I did not try to understand why it does so.
> I do not know whether somebody actually depends on that, but think it
> is unlikely because `b:changedtick` was not previously in a `b:`
> dictionary so whatever you did you needed to handle this value
> separately; actually it is more likely that something will break
> because of `b:changedtick` suddenly appearing inside a b: dictionary
> then because of `islocked('b:changedtick')` starting to return 0 in
> place of 1.
Other read-only variables are also not considered locked. Let's keep it
consistent.
> > The locking is something under user control, with :lockvar and
> > :unlockvar. Read-only and fixed are not properties the user can change.
> > Thus it's not really needed to have a function to check for that.
>
> I do not have a use-case except that it is slightly easier to check
> isfixed/isreadonly in Vim own tests then checking that
> assigning/unletting fails. Does not matter much because checking for
> failures is more robust then checking for function output.
>
> It would be needed if you plan on adding more such special variables
> to scope dictionaries in the future, to make scripts forwards
> compatible (e.g. if you need to save and restore b: dictionary
> contents it would be good idea to honor `isreadonly()` to not get
> error messages, now you may just special-case b:changedtick), but this
> idea is not backwards compatible: consider a script which used
> variable b:number and you added readonly b:number with `bufnr()` of
> this buffer. Previously legal script suddenly broken. (I also think
> this is what justifies user functions and commands forcing to begin
> with upper case letter.)
Making variables writeable just to be able to save/restore them is
tricky. It opens the possibility to write any time and cause harm.
If needed, we could add specific save and restore functions. But that's
just in general, there can be exceptions for historic reasons...
b:changedtick should never be saved/restored anyway, it only ever
increments. That is its purpose.
--
login: yes
password: I don't know, please tell me
password is incorrect
login: yes
password: incorrect
/// 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.
