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

/etc/papersize -- why loaded automatically??

Expand Messages
  • Lukas Ruf
    Dear all, whenever I open a file with vim VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 23 2005 14:37:54) Included patches: 1 Compiled by Norbert Tretkowski
    Message 1 of 6 , Dec 2, 2005
    • 0 Attachment
      Dear all,

      whenever I open a file with vim
      VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 23 2005 14:37:54)
      Included patches: 1
      Compiled by Norbert Tretkowski <nobse@...>
      on a Debian unstable system, /etc/papersize is loaded as the very last
      buffer. This buffer does not even appear in ':ls'. Why?

      I type

      vim test.cc

      The first buffer is then 'test.cc'. Typing ':ls' does not reveal that
      /etc/papersize is loaded. However, typing ':bn' changes to the
      /etc/papersize buffer. Or ':e otherfile.cc' makes otherfile.cc appear
      in buffer 3 -- and /etc/papersize does not appear in the ':ls'
      although buffer 3 is used for otherfile.cc .

      Why? How can I trace what is loaded by whom (script/plugin)?

      Thanks in advance.

      wbr,
      Lukas
      --
      Lukas Ruf <http://www.lpr.ch> | Ad Personam
      rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
      Raw IP <http://www.rawip.org> | Low Level Network Programming
      Style <http://email.rawip.org> | How to write emails
    • A. J. Mechelynck
      ... Try :ls! . Some buffers (called unlisted buffers) are invisible to the :ls command, unless you add an exclamation mark, in which case they will appear
      Message 2 of 6 , Dec 2, 2005
      • 0 Attachment
        Lukas Ruf wrote:
        > Dear all,
        >
        > whenever I open a file with vim
        > VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 23 2005 14:37:54)
        > Included patches: 1
        > Compiled by Norbert Tretkowski <nobse@...>
        > on a Debian unstable system, /etc/papersize is loaded as the very last
        > buffer. This buffer does not even appear in ':ls'. Why?
        >
        > I type
        >
        > vim test.cc
        >
        > The first buffer is then 'test.cc'. Typing ':ls' does not reveal that
        > /etc/papersize is loaded. However, typing ':bn' changes to the
        > /etc/papersize buffer. Or ':e otherfile.cc' makes otherfile.cc appear
        > in buffer 3 -- and /etc/papersize does not appear in the ':ls'
        > although buffer 3 is used for otherfile.cc .
        >
        > Why? How can I trace what is loaded by whom (script/plugin)?
        >
        > Thanks in advance.
        >
        > wbr,
        > Lukas

        Try ":ls!". Some buffers (called "unlisted" buffers) are "invisible" to
        the :ls command, unless you add an exclamation mark, in which case they
        will appear with the letter u next to their number.

        To see what buffer is loaded by which plugin, the only foolprof method
        that comes to my mind is to view the various scripts mentioned in the
        output of ":scriptnames". If you are good at guessing which plugin is
        "most likely" to have done it, it may help.

        See ":help :ls"

        Best regards,
        Tony.
      • James Vega
        ... For questions about Debian s Vim packaging, you can contact . ... In the currently released package,
        Message 3 of 6 , Dec 2, 2005
        • 0 Attachment
          On Fri, Dec 02, 2005 at 11:08:55AM +0100, Lukas Ruf wrote:
          > Dear all,
          >
          > whenever I open a file with vim
          > VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 23 2005 14:37:54)
          > Included patches: 1
          > Compiled by Norbert Tretkowski <nobse@...>
          > on a Debian unstable system,

          For questions about Debian's Vim packaging, you can contact
          <pkg-vim-maintainers@...>.

          > /etc/papersize is loaded as the very last
          > buffer. This buffer does not even appear in ':ls'. Why?

          In the currently released package, /etc/vim/vimrc reads /etc/papersize
          in order to set the paper option for 'printoptions'. This was done by
          reading the file into a buffer and then deleting the buffer via ':bd!'.
          Since we use ':bd!' you shouldn't be able to ':bn' to get to the buffer.
          At any rate, in the next package version, this will be done without
          actually loading the file into Vim, so you shouldn't have that problem.

          HTH,

          James
          --
          GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
        • Lukas Ruf
          ... Hash: SHA1 ... thanks for your answer! ... I was not sure to whom to address this question. ... definitely! This has explained anything although the
          Message 4 of 6 , Dec 2, 2005
          • 0 Attachment
            -----BEGIN PGP SIGNED MESSAGE-----
            Hash: SHA1

            > James Vega <jamessan@...> [2005-12-02 14:31]:
            >

            thanks for your answer!

            > On Fri, Dec 02, 2005 at 11:08:55AM +0100, Lukas Ruf wrote:
            > > Dear all,
            > >
            > > whenever I open a file with vim
            > > VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 23 2005 14:37:54)
            > > Included patches: 1
            > > Compiled by Norbert Tretkowski <nobse@...>
            > > on a Debian unstable system,
            >
            > For questions about Debian's Vim packaging, you can contact
            > <pkg-vim-maintainers@...>.
            >

            I was not sure to whom to address this question.

            > > /etc/papersize is loaded as the very last
            > > buffer. This buffer does not even appear in ':ls'. Why?
            >
            > In the currently released package, /etc/vim/vimrc reads /etc/papersize
            > in order to set the paper option for 'printoptions'. This was done by
            > reading the file into a buffer and then deleting the buffer via ':bd!'.
            > Since we use ':bd!' you shouldn't be able to ':bn' to get to the buffer.
            > At any rate, in the next package version, this will be done without
            > actually loading the file into Vim, so you shouldn't have that problem.
            >
            > HTH,
            >

            definitely! This has explained anything although the buffer still
            exists in any session...

            Thanks very much!

            wbr,
            Lukas
            - --
            Lukas Ruf <http://www.lpr.ch> | Ad Personam
            rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
            Raw IP <http://www.rawip.org> | Low Level Network Programming
            Style <http://email.rawip.org> | How to write emails
            -----BEGIN PGP SIGNATURE-----
            Version: GnuPG v1.4.2 (GNU/Linux)

            iD8DBQFDkE4UXf8zDoH8+EURAnNqAJ94AT9d47ScHNNxrvNdoLptpmFQUgCeNjlJ
            kpl7b48adQDt1+wE1hJX3iY=
            =GSWV
            -----END PGP SIGNATURE-----
          • Lukas Ruf
            ... thanks for your answer! ... one always learns..... Thanks very much! wbr, Lukas -- Lukas Ruf | Ad Personam rbacs
            Message 5 of 6 , Dec 2, 2005
            • 0 Attachment
              > A. J. Mechelynck <antoine.mechelynck@...> [2005-12-02 12:15]:
              >
              thanks for your answer!

              > Lukas Ruf wrote:
              >
              > Try ":ls!". Some buffers (called "unlisted" buffers) are "invisible" to
              > the :ls command, unless you add an exclamation mark, in which case they
              > will appear with the letter u next to their number.
              >
              > To see what buffer is loaded by which plugin, the only foolprof method
              > that comes to my mind is to view the various scripts mentioned in the
              > output of ":scriptnames". If you are good at guessing which plugin is
              > "most likely" to have done it, it may help.
              >
              > See ":help :ls"
              >

              one always learns..... Thanks very much!

              wbr,
              Lukas
              --
              Lukas Ruf <http://www.lpr.ch> | Ad Personam
              rbacs <http://wiki.lpr.ch> | Restaurants, Bars and Clubs
              Raw IP <http://www.rawip.org> | Low Level Network Programming
              Style <http://email.rawip.org> | How to write emails
            • A. J. Mechelynck
              ... BTW, the difference between :bdelete and :bwipeout is that the former makes the buffer unlisted, the latter really removes all trace of it (but higher
              Message 6 of 6 , Dec 2, 2005
              • 0 Attachment
                Lukas Ruf wrote:
                >> A. J. Mechelynck <antoine.mechelynck@...> [2005-12-02 12:15]:
                >>
                > thanks for your answer!
                >
                >> Lukas Ruf wrote:
                >>
                >> Try ":ls!". Some buffers (called "unlisted" buffers) are "invisible" to
                >> the :ls command, unless you add an exclamation mark, in which case they
                >> will appear with the letter u next to their number.
                >>
                >> To see what buffer is loaded by which plugin, the only foolprof method
                >> that comes to my mind is to view the various scripts mentioned in the
                >> output of ":scriptnames". If you are good at guessing which plugin is
                >> "most likely" to have done it, it may help.
                >>
                >> See ":help :ls"
                >>
                >
                > one always learns..... Thanks very much!
                >
                > wbr,
                > Lukas

                BTW, the difference between ":bdelete" and ":bwipeout" is that the
                former makes the buffer unlisted, the latter really removes all trace of
                it (but higher numbered buffers don't get a lower number).

                Best regards,
                Tony.
              Your message has been successfully submitted and would be delivered to recipients shortly.