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

Spurious command in explorer.vim plugin

Expand Messages
  • Walter Briscoe
    I was working in an area where I wanted to vim -d 6 files. I decided to change diff.c to handle a variable number of files rather than a fixed number. I was
    Message 1 of 6 , Jul 27, 2004
    • 0 Attachment
      I was working in an area where I wanted to vim -d 6 files. I decided to
      change diff.c to handle a variable number of files rather than a fixed
      number. I was able to get the new code work with 6 files.
      I am suspicious about my change. I decided to look in detail at what
      happened when I did vim -d on 5 files. I unrolled my change to diff.c.
      I still got the same failure.

      My command was vim -d t.?. I got the same response to
      vimd -d t.t t.v t.w t.x t.y:

      "t.y" 13L, 1496C
      E96: Can not diff more than 4 buffers
      Error detected while processing function <SNR>9_EditAll:
      line 13:
      E492: Not an editor command: yyyyYYYYY^H
      Hit ENTER or type command to continue

      I set verbose=20 and redirected output to a file. The spurious command
      environment was:

      ...
      line 5: endif
      line 6: if !isdirectory(name)
      line 7: return
      function <SNR>9_EditAll..<SNR>9_EditDir returning #0
      continuing in function <SNR>9_EditAll
      line 12: endwhile
      line 6: while 1
      line 7: wincmd w
      line 8: if winnr() == curwin
      line 9: break
      line 10: endif
      line 11: call s:EditDir()
      line 12: endwhile
      line 13: exe cmd
      line 13: 1resize 58|vert 1resize 28|2resize 58|vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize
      27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: vert 1resize 28|2resize 58|vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^M
      d-º‹‹‹‹‹‹‹‹
      line 13: 2resize 58|vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: 3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: 4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: vert 4resize 27|5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: 5resize 58|vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: vert 5resize 27|yyyyº^Md-º‹‹‹‹‹‹‹‹
      line 13: yyyyº^Md-º‹‹‹‹‹‹‹‹
      Error detected while processing function <SNR>9_EditAll:
      line 13:
      E492: Not an editor command: yyyyº^Md-º‹‹‹‹‹‹‹‹
      Hit ENTER or type command to continue
      function <SNR>9_EditAll returning #0
      continuing in VimEnter Auto commands for "*"
      Calling shell to execute: "diff -a C:\winnt\TEMP\VIoC3.tmp C:\winnt\TEMP\VInC4.tmp >C:\winnt\TEMP\VIdC5.tmp 2>&1"

      The following lines seem immediately relevant.
      ./runtime/plugin/explorer.vim:function! s:EditAll()
      ./runtime/plugin/explorer.vim: au VimEnter * call s:EditAll()

      I ensured I have the latest version of that file before sending this.
      I have the following directory information:
      C:\wfb\url\ftp\ftp.vim.org\pub\vim\runtime\plugin) db c:\WFB\vim\vim63\plugin\explorer.vim explorer.vim
      2004/05/13 09:06 34,714 c:\WFB\vim\vim63\plugin\explorer.vim
      2004/05/17 10:07 34,714 C:\wfb\url\ftp\ftp.vim.org\pub\vim\runtime\plugin\explorer.vim


      C:\wfb\url\ftp\ftp.vim.org\pub\vim\runtime\plugin) diff c:\WFB\vim\vim63\plugin\explorer.vim .

      C:\wfb\url\ftp\ftp.vim.org\pub\vim\runtime\plugin)

      I am SERIOUSLY ignorant about debugging vim scripts.
      I will give thanks for any help offered.
      --
      Walter Briscoe
    • Benji Fisher
      ... I assume you mean vim -d and not vimd -d . I tried it with five non-existent files as above. I get the same E96 but not the weird error. ... Here are
      Message 2 of 6 , Jul 27, 2004
      • 0 Attachment
        On Tue, Jul 27, 2004 at 04:13:14PM +0000, Walter Briscoe wrote:
        > I was working in an area where I wanted to vim -d 6 files. I decided to
        > change diff.c to handle a variable number of files rather than a fixed
        > number. I was able to get the new code work with 6 files.
        > I am suspicious about my change. I decided to look in detail at what
        > happened when I did vim -d on 5 files. I unrolled my change to diff.c.
        > I still got the same failure.
        >
        > My command was vim -d t.?. I got the same response to
        > vimd -d t.t t.v t.w t.x t.y:
        >
        > "t.y" 13L, 1496C
        > E96: Can not diff more than 4 buffers
        > Error detected while processing function <SNR>9_EditAll:
        > line 13:
        > E492: Not an editor command: yyyyYYYYY^H
        > Hit ENTER or type command to continue

        I assume you mean "vim -d" and not "vimd -d". I tried it with five
        non-existent files as above. I get the same E96 but not the weird
        error.

        > I set verbose=20 and redirected output to a file. The spurious command
        > environment was:

        Here are the first few lines of the function that had the problem,
        from $VIMRUNTIME/plugin/explorer.vim :


        function! s:EditAll()
        if winbufnr(2) == -1
        return
        endif
        let cmd = winrestcmd()
        let curwin = winnr()
        while 1

        > ...
        > line 5: endif
        > line 6: if !isdirectory(name)
        > line 7: return
        > function <SNR>9_EditAll..<SNR>9_EditDir returning #0
        > continuing in function <SNR>9_EditAll
        > line 12: endwhile
        > line 6: while 1
        > line 7: wincmd w
        > line 8: if winnr() == curwin
        > line 9: break
        > line 10: endif
        > line 11: call s:EditDir()
        > line 12: endwhile
        > line 13: exe cmd
        > line 13: 1resize 58|vert 1resize 28|2resize 58|vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize
        [snip]
        >
        > I am SERIOUSLY ignorant about debugging vim scripts.
        > I will give thanks for any help offered.

        Either there is something wrong with the built-in winrestcmd()
        function or else your copy of explorer.vim is corrupted. (At least,
        those are my first two guesses.)

        For debugging, you can add

        let g:debug_cmd = cmd
        let g:try_again = winrestcmd()

        to the s:EditAll() function right after the "let cmd" line. The g:
        prefix means that these will be global variables, not local to the
        finction. After vim has started, you can

        :echo debug_cmd
        :echo try_again

        to see what you get. Once vim has started again, check

        :scriptnames

        to see whether the explorer plugin is still #9 and then

        :debug call <SNR>9_EditAll()

        if you want to run in debug mode. See

        :help debug-mode

        and especially the part starting at

        :help >cont

        HTH --Benji Fisher
      • Walter Briscoe
        In message of Tue, 27 Jul 2004 21:38:52 in , Benji Fisher writes ... vimd.exe is the
        Message 3 of 6 , Jul 28, 2004
        • 0 Attachment
          In message <20040728013852.GN5754@...> of Tue, 27 Jul
          2004 21:38:52 in , Benji Fisher <benji@...> writes
          >On Tue, Jul 27, 2004 at 04:13:14PM +0000, Walter Briscoe wrote:
          >> I was working in an area where I wanted to vim -d 6 files. I decided to
          >> change diff.c to handle a variable number of files rather than a fixed
          >> number. I was able to get the new code work with 6 files.
          >> I am suspicious about my change. I decided to look in detail at what
          >> happened when I did vim -d on 5 files. I unrolled my change to diff.c.
          >> I still got the same failure.
          >>
          >> My command was vim -d t.?. I got the same response to
          >> vimd -d t.t t.v t.w t.x t.y:
          >>
          >> "t.y" 13L, 1496C
          >> E96: Can not diff more than 4 buffers
          >> Error detected while processing function <SNR>9_EditAll:
          >> line 13:
          >> E492: Not an editor command: yyyyYYYYY^H
          >> Hit ENTER or type command to continue
          >
          > I assume you mean "vim -d" and not "vimd -d". I tried it with five
          >non-existent files as above. I get the same E96 but not the weird
          >error.
          vimd.exe is the version built by
          nmake /nologo -f Make_ivc.mak CFG="Vim - Win32 Debug vim" all

          >
          >> I set verbose=20 and redirected output to a file. The spurious command
          >> environment was:
          >
          > Here are the first few lines of the function that had the problem,
          >from $VIMRUNTIME/plugin/explorer.vim :
          >
          >
          >function! s:EditAll()
          > if winbufnr(2) == -1
          > return
          > endif
          > let cmd = winrestcmd()
          > let curwin = winnr()
          > while 1
          >
          >> ...
          >> line 5: endif
          >> line 6: if !isdirectory(name)
          >> line 7: return
          >> function <SNR>9_EditAll..<SNR>9_EditDir returning #0
          >> continuing in function <SNR>9_EditAll
          >> line 12: endwhile
          >> line 6: while 1
          >> line 7: wincmd w
          >> line 8: if winnr() == curwin
          >> line 9: break
          >> line 10: endif
          >> line 11: call s:EditDir()
          >> line 12: endwhile
          >> line 13: exe cmd
          >> line 13: 1resize 58|vert 1resize 28|2resize 58|vert 2resize
          >>27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize
          >>58|vert 5resize
          >[snip]
          >>
          >> I am SERIOUSLY ignorant about debugging vim scripts.
          >> I will give thanks for any help offered.
          >
          > Either there is something wrong with the built-in winrestcmd()
          >function or else your copy of explorer.vim is corrupted. (At least,
          >those are my first two guesses.)
          I downloaded another explorer.vim yesterday and found no difference.

          >
          > For debugging, you can add
          >
          >let g:debug_cmd = cmd
          >let g:try_again = winrestcmd()
          >
          >to the s:EditAll() function right after the "let cmd" line. The g:
          >prefix means that these will be global variables, not local to the
          >finction. After vim has started, you can
          >
          >:echo debug_cmd
          1resize 58|vert 1resize 28|2resize 58|vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyY
          YYYY^H

          >:echo try_again
          Same value!

          >
          >to see what you get. Once vim has started again, check
          >
          >:scriptnames
          >
          >to see whether the explorer plugin is still #9 and then
          It is!

          >
          >:debug call <SNR>9_EditAll()
          >
          >if you want to run in debug mode. See
          >
          >:help debug-mode
          That is likely to be gold for me.

          >
          >and especially the part starting at
          >
          >:help >cont
          >
          >HTH --Benji Fisher
          Very much!

          :breakadd func winrestcmd did not stop when I did
          :debug call <SNR>9_EditAll()
          cont

          Ah! :help winrestcmd finds some text in eval.txt.
          It must map to C code. I am more comfortable about debugging that.

          I put a breakpoint on f_winrestcmd in eval.c.
          The problem shows at "retvar->var_val.var_string = ga.ga_data;"
          We have "[auto] garray_T ga;" and "void *ga_data;".
          ga is manipulated with ga_init2() and ga_concat().
          I shall trace ga.ga_data. Ah! It is easy! ga_concat does not NUL
          terminate ga.ga_data. I shall look elsewhere for correct code.
          get_maparg() contains "ga_append(&ga, '\000');" which seems likely to
          hit the spot. Yes! That works in and out of the debugger. Benj1, I
          suspect you did not see a failure as, in your environment, malloc(42) is
          functionally equivalent to calloc(1, 42). I prefer to run with a version
          which is less forgiving of bugs.

          Bram, I suggest the following patch:

          *** src/eval.c.0 Wed May 26 14:34:38 2004
          --- src/eval.c Wed Jul 28 07:36:55 2004
          ***************
          *** 7561,7566 ****
          --- 7561,7567 ----
          ++winnr;
          }

          + ga_append(&ga, NUL);
          retvar->var_val.var_string = ga.ga_data;
          #else
          retvar->var_val.var_string = NULL;

          --
          Walter Briscoe
        • Bram Moolenaar
          ... There is indeed a bug in winrestcmd(). The returned string is not terminated with a NUL. Your patch looks good, thanks. -- ... /// Bram Moolenaar --
          Message 4 of 6 , Jul 28, 2004
          • 0 Attachment
            Walter Briscoe wrote:

            > >let g:debug_cmd = cmd
            > >let g:try_again = winrestcmd()
            > >
            > >to the s:EditAll() function right after the "let cmd" line. The g:
            > >prefix means that these will be global variables, not local to the
            > >finction. After vim has started, you can
            > >
            > >:echo debug_cmd
            > 1resize 58|vert 1resize 28|2resize 58|vert 2resize 27|3resize 58|vert 3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyY
            > YYYY^H
            >
            > >:echo try_again
            > Same value!

            There is indeed a bug in winrestcmd(). The returned string is not
            terminated with a NUL. Your patch looks good, thanks.

            --
            From "know your smileys":
            :-| :-| Deja' vu!

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
          • Benji Fisher
            ... Right. The debug mode only works with user-defined functions, such as EditAll(); winrestcmd() is built in. User-defined functions start with capital
            Message 5 of 6 , Jul 28, 2004
            • 0 Attachment
              On Wed, Jul 28, 2004 at 07:50:58AM +0000, Walter Briscoe wrote:
              > In message <20040728013852.GN5754@...> of Tue, 27 Jul
              > 2004 21:38:52 in , Benji Fisher <benji@...> writes
              >
              > :breakadd func winrestcmd did not stop when I did
              > :debug call <SNR>9_EditAll()
              > cont
              >
              > Ah! :help winrestcmd finds some text in eval.txt.
              > It must map to C code. I am more comfortable about debugging that.

              Right. The debug mode only works with user-defined functions, such
              as EditAll(); winrestcmd() is built in. User-defined functions start
              with capital letters, and built-in functions start with lower-case
              letters.

              > I put a breakpoint on f_winrestcmd in eval.c.
              > The problem shows at "retvar->var_val.var_string = ga.ga_data;"
              > We have "[auto] garray_T ga;" and "void *ga_data;".
              > ga is manipulated with ga_init2() and ga_concat().
              > I shall trace ga.ga_data. Ah! It is easy! ga_concat does not NUL
              > terminate ga.ga_data. I shall look elsewhere for correct code.
              > get_maparg() contains "ga_append(&ga, '\000');" which seems likely to
              > hit the spot. Yes! That works in and out of the debugger. Benj1, I
              > suspect you did not see a failure as, in your environment, malloc(42) is
              > functionally equivalent to calloc(1, 42). I prefer to run with a version
              > which is less forgiving of bugs.

              So it *was* a bug with the built-in function. I am glad you were
              able to fix it.

              --Benji Fisher
            • Walter Briscoe
              In message of Wed, 28 Jul 2004 12:07:55 in , Bram Moolenaar writes ... I think there may also
              Message 6 of 6 , Jul 28, 2004
              • 0 Attachment
                In message <200407281007.i6SA7tj6017379@...> of Wed, 28 Jul
                2004 12:07:55 in , Bram Moolenaar <Bram@...> writes
                >
                >Walter Briscoe wrote:
                >
                >> >let g:debug_cmd = cmd
                >> >let g:try_again = winrestcmd()
                >> >
                >> >to the s:EditAll() function right after the "let cmd" line. The g:
                >> >prefix means that these will be global variables, not local to the
                >> >finction. After vim has started, you can
                >> >
                >> >:echo debug_cmd
                >> 1resize 58|vert 1resize 28|2resize 58|vert 2resize 27|3resize 58|vert
                >>3resize 27|4resize 58|vert 4resize 27|5resize 58|vert 5resize 27|yyyyY
                >> YYYY^H
                >>
                >> >:echo try_again
                >> Same value!
                >
                >There is indeed a bug in winrestcmd(). The returned string is not
                >terminated with a NUL. Your patch looks good, thanks.
                >
                I think there may also an effective off-by-one error in ga_grow().
                I went looking for ga_concat() usage which seemed to lack ga_append(0).
                I found ga_append(0) missing from gui_do_findrepl() and
                serverGetVimNames(). I was surprised to find gui_do_findrepl() does not
                fail. I think I can make it fail with suitable data but do not feel like
                doing so. The reason is that ga_grow() uses alloc_clear() rather than
                alloc(). As a result, ga_concat() produces a NUL-terminated string
                unless it precisely fills the ga_data space. I would be inclined to use
                alloc rather than alloc_clear() as bugs are mostly masked.

                I have patch 6.3.015. That IS fast.
                --
                Walter Briscoe
              Your message has been successfully submitted and would be delivered to recipients shortly.