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

Re: Calling autoloaded dictionary functions

Expand Messages
  • Christian Brabandt
    Hi Jim! ... What Vim version does that happen. I don t see the error with vim 7.3.854 regards, Christian -- Wir spielen Mann gegen Mann. Und ich spiel gegen
    Message 1 of 6 , Mar 23, 2013
      Hi Jim!

      On Fr, 22 Mär 2013, Jim Stewart wrote:

      > This is an old post, but I'm glad I ran into it.
      >
      > I'm fairly sure you're right about this, and that it's a bug in Vim rather than intentional behavior. I think it's a side-effect of the intended behavior that references a variable won't trigger an autoload.
      >
      > I've been going nuts trying to debug something, and this is the exact behavior I see. I'm not going to dive into the yak shaving hole and check the Vim source tonight, but this warrants some investigation. If it's intentional, I'm not sure why; powerful things could be done with this working.
      >
      > If I fix it I'll try to remember to update here. This is the only comment on the net about it that I've run across so far.

      What Vim version does that happen. I don't see the error with vim
      7.3.854


      regards,
      Christian
      --
      Wir spielen Mann gegen Mann. Und ich spiel gegen den Mann.
      -- Olaf Thon

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... It s actually in the todo list: Using :call foo#d.f() doesn t autoload the foo.vim file. That is, calling a dictionary function on an autoloaded dict.
      Message 2 of 6 , Mar 23, 2013
        Christian Brabandt wrote:

        > On Fr, 22 Mär 2013, Jim Stewart wrote:
        >
        > > This is an old post, but I'm glad I ran into it.
        > >
        > > I'm fairly sure you're right about this, and that it's a bug in Vim rather than intentional behavior. I think it's a side-effect of the intended behavior that references a variable won't trigger an autoload.
        > >
        > > I've been going nuts trying to debug something, and this is the exact behavior I see. I'm not going to dive into the yak shaving hole and check the Vim source tonight, but this warrants some investigation. If it's intentional, I'm not sure why; powerful things could be done with this working.
        > >
        > > If I fix it I'll try to remember to update here. This is the only comment on the net about it that I've run across so far.
        >
        > What Vim version does that happen. I don't see the error with vim
        > 7.3.854

        It's actually in the todo list:

        Using ":call foo#d.f()" doesn't autoload the "foo.vim" file.
        That is, calling a dictionary function on an autoloaded dict.
        Works OK for echo, just not for ":call" and ":call call()". (Ted, 2011 Mar
        17)

        --
        Warning label on a superhero Halloween costume:
        "Caution: Cape does not enable user to fly."

        /// Bram Moolenaar -- Bram@... -- 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_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Christian Brabandt
        Hi Bram! ... I see the problem: get_lval() calls find_var() with the hashtab argument set. find_var() then calls find_var_in_ht() with the third argument
        Message 3 of 6 , Mar 23, 2013
          Hi Bram!

          On Sa, 23 Mär 2013, Bram Moolenaar wrote:

          >
          > Christian Brabandt wrote:
          >
          > > On Fr, 22 Mär 2013, Jim Stewart wrote:
          > >
          > > > This is an old post, but I'm glad I ran into it.
          > > >
          > > > I'm fairly sure you're right about this, and that it's a bug in Vim rather than intentional behavior. I think it's a side-effect of the intended behavior that references a variable won't trigger an autoload.
          > > >
          > > > I've been going nuts trying to debug something, and this is the exact behavior I see. I'm not going to dive into the yak shaving hole and check the Vim source tonight, but this warrants some investigation. If it's intentional, I'm not sure why; powerful things could be done with this working.
          > > >
          > > > If I fix it I'll try to remember to update here. This is the only comment on the net about it that I've run across so far.
          > >
          > > What Vim version does that happen. I don't see the error with vim
          > > 7.3.854
          >
          > It's actually in the todo list:
          >
          > Using ":call foo#d.f()" doesn't autoload the "foo.vim" file.
          > That is, calling a dictionary function on an autoloaded dict.
          > Works OK for echo, just not for ":call" and ":call call()". (Ted, 2011 Mar
          > 17)

          I see the problem:

          get_lval() calls find_var() with the hashtab argument set. find_var()
          then calls find_var_in_ht() with the third argument being not null (e.g.
          writing flag is true). But autoloading only happens, when writing flag
          is false.

          This simple patch fixes it, but I don't know if this is correct (but at
          least the testsuite runs successfully)

          diff --git a/src/eval.c b/src/eval.c
          --- a/src/eval.c
          +++ b/src/eval.c
          @@ -2551,7 +2551,6 @@
          listitem_T *ni;
          char_u *key = NULL;
          int len;
          - hashtab_T *ht;

          /* Clear everything in "lp". */
          vim_memset(lp, 0, sizeof(lval_T));
          @@ -2599,7 +2598,7 @@

          cc = *p;
          *p = NUL;
          - v = find_var(lp->ll_name, &ht);
          + v = find_var(lp->ll_name, NULL);
          if (v == NULL && !quiet)
          EMSG2(_(e_undefvar), lp->ll_name);
          *p = cc;

          It could be possible, that this patch makes vim always source an autoload script, even if it did before. I am not 100 percent sure on that.

          regards,
          Christian
          --

          --
          --
          You received this message from the "vim_use" 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_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Bram Moolenaar
          ... Thanks, I ll check it out later. -- From know your smileys : (X0||) Double hamburger with lettuce and tomato /// Bram Moolenaar -- Bram@Moolenaar.net --
          Message 4 of 6 , Mar 23, 2013
            Christian Brabandt wrote:

            > On Sa, 23 Mär 2013, Bram Moolenaar wrote:
            >
            > >
            > > Christian Brabandt wrote:
            > >
            > > > On Fr, 22 Mär 2013, Jim Stewart wrote:
            > > >
            > > > > This is an old post, but I'm glad I ran into it.
            > > > >
            > > > > I'm fairly sure you're right about this, and that it's a bug in Vim rather than intentional behavior. I think it's a side-effect of the intended behavior that references a variable won't trigger an autoload.
            > > > >
            > > > > I've been going nuts trying to debug something, and this is the exact behavior I see. I'm not going to dive into the yak shaving hole and check the Vim source tonight, but this warrants some investigation. If it's intentional, I'm not sure why; powerful things could be done with this working.
            > > > >
            > > > > If I fix it I'll try to remember to update here. This is the only comment on the net about it that I've run across so far.
            > > >
            > > > What Vim version does that happen. I don't see the error with vim
            > > > 7.3.854
            > >
            > > It's actually in the todo list:
            > >
            > > Using ":call foo#d.f()" doesn't autoload the "foo.vim" file.
            > > That is, calling a dictionary function on an autoloaded dict.
            > > Works OK for echo, just not for ":call" and ":call call()". (Ted, 2011 Mar
            > > 17)
            >
            > I see the problem:
            >
            > get_lval() calls find_var() with the hashtab argument set. find_var()
            > then calls find_var_in_ht() with the third argument being not null (e.g.
            > writing flag is true). But autoloading only happens, when writing flag
            > is false.
            >
            > This simple patch fixes it, but I don't know if this is correct (but at
            > least the testsuite runs successfully)
            >
            > diff --git a/src/eval.c b/src/eval.c
            > --- a/src/eval.c
            > +++ b/src/eval.c
            > @@ -2551,7 +2551,6 @@
            > listitem_T *ni;
            > char_u *key = NULL;
            > int len;
            > - hashtab_T *ht;
            >
            > /* Clear everything in "lp". */
            > vim_memset(lp, 0, sizeof(lval_T));
            > @@ -2599,7 +2598,7 @@
            >
            > cc = *p;
            > *p = NUL;
            > - v = find_var(lp->ll_name, &ht);
            > + v = find_var(lp->ll_name, NULL);
            > if (v == NULL && !quiet)
            > EMSG2(_(e_undefvar), lp->ll_name);
            > *p = cc;
            >
            > It could be possible, that this patch makes vim always source an
            > autoload script, even if it did before. I am not 100 percent sure on
            > that.

            Thanks, I'll check it out later.

            --
            From "know your smileys":
            (X0||) Double hamburger with lettuce and tomato

            /// Bram Moolenaar -- Bram@... -- 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_use" 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_use" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          Your message has been successfully submitted and would be delivered to recipients shortly.