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

RE: Bug with bufexists()

Expand Messages
  • Larson, David
    Looking through the source code, I realize that this is a false alarm. The test1 Makefile is actually a link to the file shown in buffer 4, which bufexists is
    Message 1 of 4 , Dec 1, 2009
      Looking through the source code, I realize that this is a false alarm. The test1 Makefile is actually a link to the file shown in buffer 4, which bufexists is clever enough to figure out. Should the help entry for bufexists() mention that symbolic links are resolved?

      Thanks,
      David

      -----Original Message-----
      From: Larson, David
      Sent: Tuesday, December 01, 2009 12:06 PM
      To: 'vim-dev@...'
      Subject: Bug with bufexists()

      Hi folks,

      I've been working on a script of mine and found this problem. If I call this command:

      :echo bufexists("/home/mossberg/team/dalarson/mossberg/sim/tests/test1/Makefile")

      it returns 1. It should have returned 0 because this buffer doesn't exist:

      :ls!
      1 # "/home/mossberg/team/dalarson/mossberg/vcs_help.txt" line 1
      2u = "~/.vim/favorite.files" line 1
      3u h "~/.vimprojects" line 18
      4 %a "/home/mossberg/team/dalarson/mossberg/sim/tests/Makefile" line 1
      5u - "[BufExplorer]" line 1

      Buffer 4 is close, but it isn't exact. The documentation for bufexists says that if the expression is a string, then it must match a buffer name exactly.

      This looks like a clear bug to me.

      I'm running Vim 7.2, patches 1-284 on 64 bit GNU/Linux.

      Thanks,
      David

      --
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • c9s
      actually the buffer is not wiped out. so it still exist. i dont think this is a bug. you should use buflisted() function to detect buffer. ... -- You received
      Message 2 of 4 , Dec 2, 2009
        actually the buffer is not wiped out. so it still exist. i dont think
        this is a bug.

        you should use buflisted() function to detect buffer.

        On Dec 2, 7:58 am, "Larson, David" <David.Lar...@...> wrote:
        > Looking through the source code, I realize that this is a false alarm. The test1 Makefile is actually a link to the file shown in buffer 4, which bufexists is clever enough to figure out. Should the help entry for bufexists() mention that symbolic links are resolved?
        >
        > Thanks,
        > David
        >
        >
        >
        > -----Original Message-----
        > From: Larson, David
        > Sent: Tuesday, December 01, 2009 12:06 PM
        > To: 'vim-...@...'
        > Subject: Bug with bufexists()
        >
        > Hi folks,
        >
        > I've been working on a script of mine and found this problem. If I call this command:
        >
        > :echo bufexists("/home/mossberg/team/dalarson/mossberg/sim/tests/test1/Makefile")
        >
        > it returns 1. It should have returned 0 because this buffer doesn't exist:
        >
        > :ls!
        >   1 #    "/home/mossberg/team/dalarson/mossberg/vcs_help.txt" line 1
        >   2u  =  "~/.vim/favorite.files"        line 1
        >   3u h   "~/.vimprojects"               line 18
        >   4 %a   "/home/mossberg/team/dalarson/mossberg/sim/tests/Makefile" line 1
        >   5u  -  "[BufExplorer]"                line 1
        >
        > Buffer 4 is close, but it isn't exact. The documentation for bufexists says that if the expression is a string, then it must match a buffer name exactly.
        >
        > This looks like a clear bug to me.
        >
        > I'm running Vim 7.2, patches 1-284 on 64 bit GNU/Linux.
        >
        > Thanks,
        > David

        --
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
      • c9s
        oh i missed the test1 sorry. ... -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
        Message 3 of 4 , Dec 2, 2009
          oh i missed the 'test1' sorry.

          On Dec 2, 7:58 am, "Larson, David" <David.Lar...@...> wrote:
          > Looking through the source code, I realize that this is a false alarm. The test1 Makefile is actually a link to the file shown in buffer 4, which bufexists is clever enough to figure out. Should the help entry for bufexists() mention that symbolic links are resolved?
          >
          > Thanks,
          > David
          >
          >
          >
          > -----Original Message-----
          > From: Larson, David
          > Sent: Tuesday, December 01, 2009 12:06 PM
          > To: 'vim-...@...'
          > Subject: Bug with bufexists()
          >
          > Hi folks,
          >
          > I've been working on a script of mine and found this problem. If I call this command:
          >
          > :echo bufexists("/home/mossberg/team/dalarson/mossberg/sim/tests/test1/Makefile")
          >
          > it returns 1. It should have returned 0 because this buffer doesn't exist:
          >
          > :ls!
          >   1 #    "/home/mossberg/team/dalarson/mossberg/vcs_help.txt" line 1
          >   2u  =  "~/.vim/favorite.files"        line 1
          >   3u h   "~/.vimprojects"               line 18
          >   4 %a   "/home/mossberg/team/dalarson/mossberg/sim/tests/Makefile" line 1
          >   5u  -  "[BufExplorer]"                line 1
          >
          > Buffer 4 is close, but it isn't exact. The documentation for bufexists says that if the expression is a string, then it must match a buffer name exactly.
          >
          > This looks like a clear bug to me.
          >
          > I'm running Vim 7.2, patches 1-284 on 64 bit GNU/Linux.
          >
          > Thanks,
          > David

          --
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
        Your message has been successfully submitted and would be delivered to recipients shortly.