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

':buffer' and command line completion inconsistent with ':ls'

Expand Messages
  • Wiktor Ruben
    Hello, I use Vim 7.4.5. Let me start with some prerequisities: ~ $ mkdir foobar ~ $ cd foobar ~/foobar $ touch foo bar baz ~/foobar $ vim -u NONE foo bar baz
    Message 1 of 4 , Sep 11, 2013
    • 0 Attachment
      Hello,

      I use Vim 7.4.5. Let me start with some prerequisities:

      ~ $ mkdir foobar
      ~ $ cd foobar
      ~/foobar $ touch foo bar baz
      ~/foobar $ vim -u NONE foo bar baz

      Now, make the observation that:

      :ls
      1 %a "foo" line 1
      2 "bar" line 0
      3 "baz" line 0

      That being so when I do:

      :buffer foo<CTRL-D>

      I expect to see only 'foo' buffer. Instead I've got this:

      foo ~/foobar/bar ~/foobar/baz

      I presume this happens because there is 'foo' substring in the absolute
      path for buffers 'bar' and 'baz'. This behaviour is totally wrong
      because for the sake of consistency ':buffer' should match against
      buffer name as displayed by ':ls', not file name absolute path.

      But let us assume for a moment that this behaviour is correct. Then:

      :buffer bar<CTRL-D>

      should display analogous results (because 'bar' is a substring in the
      absolute path for all files). That is:

      ~/foobar/foo bar ~/foobar/baz

      Instead we are given only:

      bar

      Could someone please explain me this behaviour?

      --
      --
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Nikolay Pavlov
      ... Not only a substring, but it also starts one component of a path. This should be the reason. ... vim_dev group. ... email to
      Message 2 of 4 , Sep 11, 2013
      • 0 Attachment


        On Sep 11, 2013 8:13 PM, "Wiktor Ruben" <smieciarski@...> wrote:
        >
        > Hello,
        >
        > I use Vim 7.4.5. Let me start with some prerequisities:
        >
        >     ~ $ mkdir foobar
        >     ~ $ cd foobar
        >     ~/foobar $ touch foo bar baz
        >     ~/foobar $ vim -u NONE foo bar baz
        >
        > Now, make the observation that:
        >
        >     :ls
        >     1 %a   "foo"                          line 1
        >     2      "bar"                          line 0
        >     3      "baz"                          line 0
        >
        > That being so when I do:
        >
        >     :buffer foo<CTRL-D>
        >
        > I expect to see only 'foo' buffer. Instead I've got this:
        >
        >     foo ~/foobar/bar ~/foobar/baz
        >
        > I presume this happens because there is 'foo' substring in the absolute
        > path for buffers 'bar' and 'baz'. This behaviour is totally wrong
        > because for the sake of consistency ':buffer' should match against
        > buffer name as displayed by ':ls', not file name absolute path.
        >
        > But let us assume for a moment that this behaviour is correct. Then:
        >
        >     :buffer bar<CTRL-D>
        >
        > should display analogous results (because 'bar' is a substring in the
        > absolute path for all files). That is:

        Not only a substring, but it also starts one component of a path. This should be the reason.

        >     ~/foobar/foo bar ~/foobar/baz
        >
        > Instead we are given only:
        >
        >     bar
        >
        > Could someone please explain me this behaviour?
        >
        > --
        > --
        > 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 vim_dev+unsubscribe@....
        > For more options, visit https://groups.google.com/groups/opt_out.

        --
        --
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Wiktor Ruben
        ... Ok, it makes sense. But what about the first part of my post, before But let us assume for a moment that this behaviour is correct ? There is neither
        Message 3 of 4 , Sep 13, 2013
        • 0 Attachment
          On Wednesday, September 11, 2013 6:36:28 PM UTC+2, ZyX wrote:
          > > But let us assume for a moment that this behaviour is correct. Then:
          >
          > >
          >
          > >     :buffer bar<CTRL-D>
          >
          > >
          >
          > > should display analogous results (because 'bar' is a substring in the
          >
          > > absolute path for all files). That is:
          >
          > Not only a substring, but it also starts one component of a path. This should be the reason.

          Ok, it makes sense. But what about the first part of my post, before
          "But let us assume for a moment that this behaviour is correct"?

          There is neither buffer named '~/foobar/bar' nor '~/foobar/baz'. There
          are only 'bar' and 'baz' buffers. The results returned by either ':ls'
          or '<CTRL-D>' are incorrect.

          It is very annoying while working with my current project. ':ls' returns
          buffers names relative to the root folder of my project but '<CTRL-D>'
          or 'TAB' (with 'wildmenu' enabled) sometimes (as in described scenario)
          distracts me with very long, unreadable absolute paths.

          --
          --
          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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • ZyX
          ... // A: :h bufname() says that ôresult is the name of a buffer, as it is displayed by :ls commandö. Also note that vim has :cd and :lcd. This would force
          Message 4 of 4 , Sep 13, 2013
          • 0 Attachment
            > Ok, it makes sense. But what about the first part of my post, before
            > "But let us assume for a moment that this behaviour is correct"?
            >
            > There is neither buffer named '~/foobar/bar' nor '~/foobar/baz'. There
            > are only 'bar' and 'baz' buffers. The results returned by either ':ls'
            > or '<CTRL-D>' are incorrect.

            :h :ls does not mention anywhere that it contains buffer names. What makes you think it does?

            // A: :h bufname() says that “result is the name of a buffer, as it is displayed by ":ls" command”.

            Also note that vim has :cd and :lcd. This would force buffer name recalculation every time you do :cd or change to another buffer. Would if vim did not keep full names as buffer names. You can see them from python interface: `vim.current.buffer.name` takes buffer name directly from C structure that represents current buffer without any modifications. Guess :b completion just does not perform these modifications thus you see what you see.

            Note that I do not think this behavior is good or consistent, but the above paragraph explains why you see it.

            > It is very annoying while working with my current project. ':ls' returns
            > buffers names relative to the root folder of my project but '<CTRL-D>'
            > or 'TAB' (with 'wildmenu' enabled) sometimes (as in described scenario)
            > distracts me with very long, unreadable absolute paths.

            I would really suggest using Command-T for switching buffers. What you complain here about is yet another reason for :b <C-d> being inefficient.

            --
            --
            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 vim_dev+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.