Loading ...
Sorry, an error occurred while loading the content.

if_lua patch

Expand Messages
  • Luis Carvalho
    Hi list, I m attaching two patches for if_lua (if_lua.c and docs in if_lua.txt). It fixes (and simplifies) luaV_list_add and introduces a new feature:
    Message 1 of 13 , Aug 26, 2012
    • 0 Attachment
      Hi list,

      I'm attaching two patches for if_lua (if_lua.c and docs in if_lua.txt). It
      fixes (and simplifies) luaV_list_add and introduces a new feature: funcrefs. I
      think that with this patch if_lua is now feature complete. :) Any feedback is,
      of course, welcome!

      Cheers,
      Luis

      --
      Computers are useless. They can only give you answers.
      -- Pablo Picasso

      --
      Luis Carvalho (Kozure)
      lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'

      --
      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
    • ZyX
      ... Wondering whether it will support translating lua tables into vim dictionaries. And also something like vim.list({ first , second , ...}) to convert
      Message 2 of 13 , Aug 29, 2012
      • 0 Attachment
        воскресенье, 26 августа 2012 г., 19:26:06 UTC+4 пользователь Luis Carvalho написал:
        > I'm attaching two patches for if_lua (if_lua.c and docs in if_lua.txt). It
        > fixes (and simplifies) luaV_list_add and introduces a new feature: funcrefs. I
        > think that with this patch if_lua is now feature complete. :) Any feedback is,
        > of course, welcome!

        Wondering whether it will support translating lua tables into vim dictionaries. And also something like "vim.list({"first", "second", ...})" to convert common lua replacement for arrays into vim List. Writing wrapper for every plugin wanting to return complex structure into VimL code does not look like a good idea.

        By the way, why "luaeval('{}')" returns "0" instead of throwing an error?

        --
        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
      • Luis Carvalho
        ... Thanks for the feedback! Since there s no one-to-one relation between Lua tables and Vim dictionaries, I ve avoided such conversions and left it to the
        Message 3 of 13 , Aug 29, 2012
        • 0 Attachment
          ZyX wrote:
          > воскресенье, 26 августа 2012 г., 19:26:06 UTC+4 пользователь Luis Carvalho написал:
          > > I'm attaching two patches for if_lua (if_lua.c and docs in if_lua.txt). It
          > > fixes (and simplifies) luaV_list_add and introduces a new feature: funcrefs. I
          > > think that with this patch if_lua is now feature complete. :) Any feedback is,
          > > of course, welcome!
          >
          > Wondering whether it will support translating lua tables into vim
          > dictionaries. And also something like "vim.list({"first", "second", ...})"
          > to convert common lua replacement for arrays into vim List. Writing wrapper
          > for every plugin wanting to return complex structure into VimL code does not
          > look like a good idea.

          Thanks for the feedback!

          Since there's no one-to-one relation between Lua tables and Vim dictionaries,
          I've avoided such conversions and left it to the user to come up with them as
          needed (for instance, cyclic references can be tricky, some tables are meant
          to be Vim lists, and so on.)

          But you're right about using tables as initializers for lists (and dicts) -- I
          guess I got lazy before and was waiting for someone to ask about these :) --
          and so I'm attaching an updated patch. You can now do:

          :lua l = vim.list{math.pi, true, 'hello!'} -- l = [3.141569, 1, 'hello!']
          :lua d = vim.dict{list = l, msg = 'hi!', n = #l} -- d = {'n': 3.0, ...}

          > By the way, why "luaeval('{}')" returns "0" instead of throwing an error?

          Two reasons: luaeval depends on a conversion routine and I don't want to throw
          an error whenever a Lua value cannot be converted to a Vim type; and I usually
          avoid throwing errors if they can be thrown by the user based on a returned
          value, as it is the case here.

          I've also updated the documentation to mention that only numbers, strings,
          booleans, and list, dict, and funcref userdata are converted to Vim equivalent
          types. All other Lua values are converted to zero.

          Cheers,
          Luis

          --
          Computers are useless. They can only give you answers.
          -- Pablo Picasso

          --
          Luis Carvalho (Kozure)
          lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'
          --
          Computers are useless. They can only give you answers.
          -- Pablo Picasso

          --
          Luis Carvalho (Kozure)
          lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'

          --
          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
        • ZyX
          ... 1 . Without +float it is worse. Depending on the plugin it may be an issue, and it definitely prevents anybody from writing a wrapper for luaeval that will
          Message 4 of 13 , Aug 30, 2012
          • 0 Attachment
            > > By the way, why "luaeval('{}')" returns "0" instead of throwing an error?
            >
            > Two reasons: luaeval depends on a conversion routine and I don't want to throw
            > an error whenever a Lua value cannot be converted to a Vim type; and I usually
            > avoid throwing errors if they can be thrown by the user based on a returned
            > value, as it is the case here.
            :echo luaeval('{}') is luaeval('false')
            1
            . Without +float it is worse. Depending on the plugin it may be an issue, and it definitely prevents anybody from writing a wrapper for luaeval that will throw an error in case of failed conversion.

            I also don’t like the idea of such implicit conversion that gives not a single clue about the source of invalid value (if it were stringified like mzeval() claims to do it would be easier to guess where invalid input is received. Explicit error like in my py*eval() is better because you immediately see error line number) and with vim ability to convert numbers to strings or floats shown error may be actually far away from the real one, if there will be any (and not silent unexpected behavior).

            --
            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
          • Luis Carvalho
            ... OK, point taken. I m now throwing an error whenever an illegal conversion is attempted; please check the updated patches (if_lua.c and if_lua.txt.)
            Message 5 of 13 , Aug 30, 2012
            • 0 Attachment
              ZyX wrote:
              > > > By the way, why "luaeval('{}')" returns "0" instead of throwing an error?
              > >
              > > Two reasons: luaeval depends on a conversion routine and I don't want to throw
              > > an error whenever a Lua value cannot be converted to a Vim type; and I usually
              > > avoid throwing errors if they can be thrown by the user based on a returned
              > > value, as it is the case here.
              > :echo luaeval('{}') is luaeval('false')
              > 1
              > . Without +float it is worse. Depending on the plugin it may be an issue, and it definitely prevents anybody from writing a wrapper for luaeval that will throw an error in case of failed conversion.
              >
              > I also don’t like the idea of such implicit conversion that gives not a single clue about the source of invalid value (if it were stringified like mzeval() claims to do it would be easier to guess where invalid input is received. Explicit error like in my py*eval() is better because you immediately see error line number) and with vim ability to convert numbers to strings or floats shown error may be actually far away from the real one, if there will be any (and not silent unexpected behavior).

              OK, point taken. I'm now throwing an error whenever an "illegal" conversion is
              attempted; please check the updated patches (if_lua.c and if_lua.txt.) Thanks
              again for the feedback!

              Cheers,
              Luis

              --
              Computers are useless. They can only give you answers.
              -- Pablo Picasso

              --
              Luis Carvalho (Kozure)
              lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'

              --
              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
            • ZyX
              Wondering whether you have repository with all these changes. After encountering this error in if_py* found it in your interface also: vim -u NONE -c let d={}
              Message 6 of 13 , Sep 1 7:35 AM
              • 0 Attachment
                Wondering whether you have repository with all these changes.

                After encountering this error in if_py* found it in your interface also:

                vim -u NONE -c 'let d={} | lua vim.eval("d")[""]=1' -c 'echo d'

                outputs “{'': 1.0}” while it should output error and “{}”: vim does not allow empty keys in dictionaries (it does not look like it breaks something except that doing “d['']” results in an error).

                And you have missed another error:

                vim -u NONE -c 'lua vim.eval("g:")["input"]=vim.funcref("tr")' -c 'call input("Yes?")'

                results in an error “not enough arguments to tr” while it should result in an error “funcref variables must start with a capital” (see my patch to python interface [1] and extend() function [2]).

                [1]: https://bitbucket.org/ZyX_I/vim/changeset/04a10416736c810bc885ae54196370f2b91ee17d
                [2]: https://bitbucket.org/ZyX_I/vim/changeset/085f14642fe828b1cbae5706ca87f2932cebeb75

                --
                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
              • ZyX
                ... No error, but g:dict is empty. Very distracting. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text
                Message 7 of 13 , Sep 1 7:42 AM
                • 0 Attachment
                  пятница, 31 августа 2012 г., 3:01:10 UTC+4 пользователь Luis Carvalho написал:
                  > OK, point taken. I'm now throwing an error whenever an "illegal" conversion is
                  > attempted; please check the updated patches (if_lua.c and if_lua.txt.) Thanks
                  > again for the feedback!

                  :lua vim.eval('g:').dict=vim.dict{'abc'}

                  No error, but g:dict is empty. Very distracting.

                  --
                  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
                • ZyX
                  ... Though mentioned in docs. Won’t be so distracting if I read them first. -- You received this message from the vim_dev maillist. Do not top-post! Type
                  Message 8 of 13 , Sep 1 7:52 AM
                  • 0 Attachment
                    > :lua vim.eval('g:').dict=vim.dict{'abc'}
                    >
                    > No error, but g:dict is empty. Very distracting.

                    Though mentioned in docs. Won’t be so distracting if I read them first.

                    --
                    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
                  • Luis Carvalho
                    ... No, since the patches are few and far between. ... I don t think that s an error in if_lua: the documentation doesn t say anything about dictionaries not
                    Message 9 of 13 , Sep 1 9:38 AM
                    • 0 Attachment
                      > Wondering whether you have repository with all these changes.

                      No, since the patches are few and far between.

                      > After encountering this error in if_py* found it in your interface also:
                      >
                      > vim -u NONE -c 'let d={} | lua vim.eval("d")[""]=1' -c 'echo d'
                      >
                      > outputs “{'': 1.0}” while it should output error and “{}”: vim does not allow empty keys in dictionaries (it does not look like it breaks something except that doing “d['']” results in an error).

                      I don't think that's an error in if_lua: the documentation doesn't say
                      anything about dictionaries not allowing empty strings as keys -- :help
                      Dictionary only says that 'a key is always a String' -- and hence the absence
                      of error when printing d in your example. What is not allowed is for you to
                      read or set empty keys in Vim (using 'let'), but I don't want to replicate
                      that in if_lua. For instance, you can do this:

                      vim -u NONE -c 'let d={} | lua vim.eval("d")[""] = "empty"'
                      -c 'for [k,v] in items(d) | echo "|".k."| -> ".v | endfor'

                      So, to be consistent, if you set an empty key in if_lua, you can read or reset
                      it there.

                      > And you have missed another error:
                      >
                      > vim -u NONE -c 'lua vim.eval("g:")["input"]=vim.funcref("tr")' -c 'call input("Yes?")'
                      >
                      > results in an error “not enough arguments to tr” while it should result in an error “funcref variables must start with a capital” (see my patch to python interface [1] and extend() function [2]).

                      There's no error here either. The problem is that tr() expects three
                      arguments, and not that the variable must start with a capital letter (g:input
                      already exists.) Try this:

                      vim -u NONE -c 'lua vim.eval("g:").input=vim.funcref("tolower")'
                      -c 'echo input("Yes?")'

                      I think you're mixing the fact that Vim Funcref variables should start with a
                      capital letter. Funcrefs in lua are just a value; for instance, this should
                      work:

                      :lua print(vim.funcref"tr"("<tag>", "<>", "{}"))
                      " {tag}

                      Thanks for the comments!

                      Cheers,
                      Luis


                      --
                      Computers are useless. They can only give you answers.
                      -- Pablo Picasso

                      --
                      Luis Carvalho (Kozure)
                      lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'

                      --
                      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
                    • Luis Carvalho
                      ... or ... since you forgot the key. Cheers, Luis -- Computers are useless. They can only give you answers. -- Pablo Picasso -- Luis Carvalho (Kozure) lua -e
                      Message 10 of 13 , Sep 1 9:41 AM
                      • 0 Attachment
                        > > :lua vim.eval('g:').dict=vim.dict{'abc'}
                        > >
                        > > No error, but g:dict is empty. Very distracting.
                        >
                        > Though mentioned in docs. Won’t be so distracting if I read them first.

                        Right. I think you meant:

                        :lua vim.eval('g:').list = vim.list{'abc'}

                        or

                        :lua vim.eval('g:').dict = vim.dict{key = 'abc'}

                        since you forgot the key.

                        Cheers,
                        Luis

                        --
                        Computers are useless. They can only give you answers.
                        -- Pablo Picasso

                        --
                        Luis Carvalho (Kozure)
                        lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'

                        --
                        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
                      • ZyX ZyX
                        ... Pulling patches from the repository and saving them there is convenient. When I was adding third argument to sort() patch was also not big but I still
                        Message 11 of 13 , Sep 1 12:55 PM
                        • 0 Attachment
                          2012/9/1 Luis Carvalho <lexcarvalho@...>:
                          >> Wondering whether you have repository with all these changes.
                          >
                          > No, since the patches are few and far between.

                          Pulling patches from the repository and saving them there is
                          convenient. When I was adding third argument to sort() patch was also
                          not big but I still cloned vim to bitbucket. This decision appeared to
                          be right when I started to extend python interface.

                          Even if you don’t want to create commits, do use “hg diff”. Two
                          patches for two files with requirement to switch to another directory
                          before applying each one is very inconvenient.

                          >> After encountering this error in if_py* found it in your interface also:
                          >>
                          >> vim -u NONE -c 'let d={} | lua vim.eval("d")[""]=1' -c 'echo d'
                          >>
                          >> outputs “{'': 1.0}” while it should output error and “{}”: vim does not allow empty keys in dictionaries (it does not look like it breaks something except that doing “d['']” results in an error).
                          >
                          > I don't think that's an error in if_lua: the documentation doesn't say
                          > anything about dictionaries not allowing empty strings as keys -- :help
                          > Dictionary only says that 'a key is always a String' -- and hence the absence
                          > of error when printing d in your example. What is not allowed is for you to
                          > read or set empty keys in Vim (using 'let'), but I don't want to replicate
                          > that in if_lua. For instance, you can do this:
                          >
                          > vim -u NONE -c 'let d={} | lua vim.eval("d")[""] = "empty"'
                          > -c 'for [k,v] in items(d) | echo "|".k."| -> ".v | endfor'
                          >
                          > So, to be consistent, if you set an empty key in if_lua, you can read or reset
                          > it there.

                          Yes, you can do “for [k, v] in items(d)”. But you can’t do “for k in
                          keys(d) | let v=d[k]”. I can’t prove that this won’t break anything,
                          maybe you can?

                          Help does not mention this probably because error message is clear
                          enough, I constantly see such things in a doc: “:h E???” exists, but
                          in the text there is nothing concerning error message.

                          >
                          >> And you have missed another error:
                          >>
                          >> vim -u NONE -c 'lua vim.eval("g:")["input"]=vim.funcref("tr")' -c 'call input("Yes?")'
                          >>
                          >> results in an error “not enough arguments to tr” while it should result in an error “funcref variables must start with a capital” (see my patch to python interface [1] and extend() function [2]).
                          >
                          > There's no error here either. The problem is that tr() expects three
                          > arguments, and not that the variable must start with a capital letter (g:input
                          > already exists.) Try this:
                          >
                          > vim -u NONE -c 'lua vim.eval("g:").input=vim.funcref("tolower")'
                          > -c 'echo input("Yes?")'

                          It is just an example. Vim has very weird way of disallowing
                          overriding built-in and user functions: a check everywhere you can add
                          a value to a dictionary. The fact that you *allow overriding built-in
                          functions* is an error. Not the fact that “tr” expects three arguments
                          or something else.

                          Existence of your behavior in lua interface and my in python (unlike
                          my patch to extend() patch to if_py* was not merged) defeats the
                          purpose of such checks.

                          >
                          > I think you're mixing the fact that Vim Funcref variables should start with a
                          > capital letter. Funcrefs in lua are just a value; for instance, this should
                          > work:
                          >
                          > :lua print(vim.funcref"tr"("<tag>", "<>", "{}"))
                          > " {tag}

                          No, I am not. I do not care how you can name funcrefs in lua, you must
                          not allow using lua to override built-in or user functions by adding
                          something to scope dictionary. The proper way of fixing this all is
                          modifying parser, but modifying lua interface is much simpler. If you
                          can modify the parser go ahead and get rid of E704 and E705: in the
                          current state there is exactly no way to safely assign funcref to a
                          variable, only to dictionary key/list item. I can see why parser does
                          this (deref_func_name: it first tries to get a funcref variable and
                          returns name as-is in case of failure), but unsure how to fix it
                          properly (quick fix is returning name as-is if find_internal_func
                          returned something other than -1 or find_func — other than NULL). I
                          also don’t think this fix will be accepted by Bram: it only pretends
                          to solve a problem as now masking functions by variables is replaced
                          by masking variables by a functions:

                          let input="abc"
                          may work properly but

                          function Input()
                          return getchar()
                          endfunction
                          let Input=function('input')
                          call Input("abc")
                          won’t.

                          --
                          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
                        • ZyX
                          ... No, I meant exactly what I typed. Before reading docs expected behavior was either converting it to “{ 1 : abc }” or an error. -- You received this
                          Message 12 of 13 , Sep 1 1:00 PM
                          • 0 Attachment
                            > Right. I think you meant:
                            >
                            > :lua vim.eval('g:').list = vim.list{'abc'}
                            >
                            > or
                            >
                            > :lua vim.eval('g:').dict = vim.dict{key = 'abc'}
                            >
                            > since you forgot the key.

                            No, I meant exactly what I typed. Before reading docs expected behavior was either converting it to “{"1": "abc"}” or an error.

                            --
                            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
                          • Luis Carvalho
                            ... OK, thanks for the suggestion. I m attaching a patch generated by hg diff . To summarize the main changes: - New funcref type, including new vim.funcref()
                            Message 13 of 13 , Sep 1 5:38 PM
                            • 0 Attachment
                              ZyX wrote:
                              > > No, since the patches are few and far between.
                              >
                              > Pulling patches from the repository and saving them there is
                              > convenient. When I was adding third argument to sort() patch was also
                              > not big but I still cloned vim to bitbucket. This decision appeared to
                              > be right when I started to extend python interface.
                              >
                              > Even if you don’t want to create commits, do use “hg diff”. Two
                              > patches for two files with requirement to switch to another directory
                              > before applying each one is very inconvenient.

                              OK, thanks for the suggestion. I'm attaching a patch generated by 'hg diff'.
                              To summarize the main changes:

                              - New funcref type, including new vim.funcref() function
                              - vim.dict() and vim.list() now accept an initializer table as argument
                              - Updated docs
                              - A few bug fixes (following this thread)


                              > > I don't think that's an error in if_lua: the documentation doesn't say
                              > > anything about dictionaries not allowing empty strings as keys -- :help
                              > > Dictionary only says that 'a key is always a String' -- and hence the absence
                              > > of error when printing d in your example. What is not allowed is for you to
                              > > read or set empty keys in Vim (using 'let'), but I don't want to replicate
                              > > that in if_lua. For instance, you can do this:
                              > >
                              > > vim -u NONE -c 'let d={} | lua vim.eval("d")[""] = "empty"'
                              > > -c 'for [k,v] in items(d) | echo "|".k."| -> ".v | endfor'
                              > >
                              > > So, to be consistent, if you set an empty key in if_lua, you can read or reset
                              > > it there.
                              >
                              > Yes, you can do “for [k, v] in items(d)”. But you can’t do “for k in
                              > keys(d) | let v=d[k]”. I can’t prove that this won’t break anything,
                              > maybe you can?
                              >
                              > Help does not mention this probably because error message is clear
                              > enough, I constantly see such things in a doc: “:h E???” exists, but
                              > in the text there is nothing concerning error message.

                              I agree that there must be a reason for the parser to avoid empty strings, but
                              then the documentation should change to reflect this behavior. Ideally this
                              behavior should be coded in the API, probably making dict_add check the
                              dictitem argument. While I still maintain that that's not an if_lua issue,
                              I've updated the code to check for empty keys when setting dict entries, just
                              in case it breaks something and for consistency.

                              > >> And you have missed another error:
                              > >>
                              > >> vim -u NONE -c 'lua vim.eval("g:")["input"]=vim.funcref("tr")' -c 'call input("Yes?")'
                              > >>
                              > >> results in an error “not enough arguments to tr” while it should result in an error “funcref variables must start with a capital” (see my patch to python interface [1] and extend() function [2]).
                              > >
                              > > There's no error here either. The problem is that tr() expects three
                              > > arguments, and not that the variable must start with a capital letter (g:input
                              > > already exists.) Try this:
                              > >
                              > > vim -u NONE -c 'lua vim.eval("g:").input=vim.funcref("tolower")'
                              > > -c 'echo input("Yes?")'
                              >
                              > It is just an example. Vim has very weird way of disallowing
                              > overriding built-in and user functions: a check everywhere you can add
                              > a value to a dictionary. The fact that you *allow overriding built-in
                              > functions* is an error. Not the fact that “tr” expects three arguments
                              > or something else.
                              >
                              > Existence of your behavior in lua interface and my in python (unlike
                              > my patch to extend() patch to if_py* was not merged) defeats the
                              > purpose of such checks.

                              Again, the issue here is not that funcref variables must start with a capital
                              letter -- only the parser should check that, not if_lua -- but that if_lua is
                              assigning funcrefs to a "builtin" scope dictionary (g: or l:). The fix is
                              straightforward: if_lua now checks if dict->dv_scope == VAR_DEF_SCOPE and if
                              the value is a funcref and complains if that's the case.

                              > > I think you're mixing the fact that Vim Funcref variables should start with a
                              > > capital letter. Funcrefs in lua are just a value; for instance, this should
                              > > work:
                              > >
                              > > :lua print(vim.funcref"tr"("<tag>", "<>", "{}"))
                              > > " {tag}
                              >
                              > No, I am not. I do not care how you can name funcrefs in lua, you must
                              > not allow using lua to override built-in or user functions by adding
                              > something to scope dictionary. The proper way of fixing this all is
                              > modifying parser, but modifying lua interface is much simpler. If you

                              As I said, you shouldn't really care about Lua "naming" funcrefs, since that's
                              a moot point (funcrefs in Lua are just values, they have no names.) But you're
                              right that the issue is checking for the dictionary to be a scope; see comment
                              above.

                              > can modify the parser go ahead and get rid of E704 and E705: in the
                              > current state there is exactly no way to safely assign funcref to a
                              > variable, only to dictionary key/list item. I can see why parser does
                              > this (deref_func_name: it first tries to get a funcref variable and
                              > returns name as-is in case of failure), but unsure how to fix it
                              > properly (quick fix is returning name as-is if find_internal_func
                              > returned something other than -1 or find_func — other than NULL). I
                              > also don’t think this fix will be accepted by Bram: it only pretends
                              > to solve a problem as now masking functions by variables is replaced
                              > by masking variables by a functions:
                              >
                              > let input="abc"
                              > may work properly but
                              >
                              > function Input()
                              > return getchar()
                              > endfunction
                              > let Input=function('input')
                              > call Input("abc")
                              > won’t.

                              You lost me in this last example and the masking comment, but I believe I do
                              not need to change the parser (and shouldn't need to.)

                              ZyX wrote:
                              > > Right. I think you meant:
                              > >
                              > > :lua vim.eval('g:').list = vim.list{'abc'}
                              > >
                              > > or
                              > >
                              > > :lua vim.eval('g:').dict = vim.dict{key = 'abc'}
                              > >
                              > > since you forgot the key.
                              >
                              > No, I meant exactly what I typed. Before reading docs expected behavior was either converting it to “{"1": "abc"}” or an error.

                              Ah, I see: you wanted to check for an error since {'abc'} is not valid in Vim.
                              I've changed the behavior to be more in line with Lua (and Vim) since numbers
                              are usually converted to strings: now vim.dict{'abc'} returns {'1': 'abc'}.

                              Thanks once again for your feedback and thorough tests!

                              Cheers,
                              Luis

                              --
                              Computers are useless. They can only give you answers.
                              -- Pablo Picasso

                              --
                              Luis Carvalho (Kozure)
                              lua -e 'print((("lexcarvalho@..."):gsub("(%u+%.)","")))'

                              --
                              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
                            Your message has been successfully submitted and would be delivered to recipients shortly.