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

'set rtp' output is truncated to 1023 bytes on Windows 7

Expand Messages
  • tyru
    Hi list. If runtimepath string exceeds 1024 bytes, set rtp output is truncated to 1023 bytes. Although runtimepath value seems to have complete string
    Message 1 of 9 , May 11, 2013
    • 0 Attachment
      Hi list.

      If 'runtimepath' string exceeds 1024 bytes,
      'set rtp' output is truncated to 1023 bytes.

      Although 'runtimepath' value seems to have complete string value
      which exceeds 1024 bytes.
      I could see the complete string value by '<C-r>=&rtp<CR>' in insert mode.

      Hirohito Higashi(a.k.a. h_east) checked Vim source code and told me that:
      1. display string length of options is limited to 'MAXPATHL - 1' in
      option_value2string() (in option.c: L10981 ... L10987).
      2. MAXPATHL is 1024 on MS Windows.

      Thanks

      --
      --
      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.
    • 0xBADDCAFE
      Hi. I had this behavior. Nowadays modern plugin managers add many runtimepath that contain scripts. These path strings can be over 1024 bytes easily. I hope to
      Message 2 of 9 , Sep 10, 2014
      • 0 Attachment
        Hi.

        I had this behavior.

        Nowadays modern plugin managers add many runtimepath that contain scripts.
        These path strings can be over 1024 bytes easily.

        I hope to fix this behavior sometime soon.

        Thanks.


        2013年5月11日土曜日 23時45分03秒 UTC+9 tyru:
        > Hi list.
        >
        >
        >
        > If 'runtimepath' string exceeds 1024 bytes,
        >
        > 'set rtp' output is truncated to 1023 bytes.
        >
        >
        >
        > Although 'runtimepath' value seems to have complete string value
        >
        > which exceeds 1024 bytes.
        >
        > I could see the complete string value by '<C-r>=&rtp<CR>' in insert mode.
        >
        >
        >
        > Hirohito Higashi(a.k.a. h_east) checked Vim source code and told me that:
        >
        > 1. display string length of options is limited to 'MAXPATHL - 1' in
        >
        > option_value2string() (in option.c: L10981 ... L10987).
        >
        > 2. MAXPATHL is 1024 on MS Windows.
        >
        >
        >
        > Thanks

        --
        --
        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/d/optout.
      • Nazri Ramliy
        ... Perhaps a new option would be better, runtimedir - all directory found in there are regarded as individual runtimepath elements. This would make giant,
        Message 3 of 9 , Sep 10, 2014
        • 0 Attachment
          On Wed, Sep 10, 2014 at 11:58 PM, 0xBADDCAFE <b607427@...> wrote:
          > Nowadays modern plugin managers add many runtimepath that contain scripts.
          > These path strings can be over 1024 bytes easily.

          Perhaps a new option would be better, 'runtimedir' - all directory found in
          there are regarded as individual runtimepath elements. This would make giant,
          unreadable 'runtimepath' values go away. glob() can help achieving
          deterministic addon loading order, so we can prefix the directory names in
          'runtimedir' with numbers to enforce ordering if necessary.

          Those who are familiar with apache2 would notice the similarity of
          enabling/disabling modules by making a symlink from one directory to another.

          Nazri

          --
          --
          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/d/optout.
        • Bram Moolenaar
          ... Although removing arbitrary limits is good, making runtimepath very long is a bad idea. Every time Vim searches for a runtime file it will visit those
          Message 4 of 9 , Sep 11, 2014
          • 0 Attachment
            Nazri Ramliy wrote:

            > On Wed, Sep 10, 2014 at 11:58 PM, 0xBADDCAFE <b607427@...> wrote:
            > > Nowadays modern plugin managers add many runtimepath that contain scripts.
            > > These path strings can be over 1024 bytes easily.
            >
            > Perhaps a new option would be better, 'runtimedir' - all directory found in
            > there are regarded as individual runtimepath elements. This would make giant,
            > unreadable 'runtimepath' values go away. glob() can help achieving
            > deterministic addon loading order, so we can prefix the directory names in
            > 'runtimedir' with numbers to enforce ordering if necessary.
            >
            > Those who are familiar with apache2 would notice the similarity of
            > enabling/disabling modules by making a symlink from one directory to another.

            Although removing arbitrary limits is good, making 'runtimepath' very
            long is a bad idea. Every time Vim searches for a runtime file it will
            visit those directories and request the contents.

            A plugin manager better use another mechanism. A dictionary to lookup
            what file is located where is a LOT faster.

            --
            Would you care for a drink? I mean, if it were, like,
            disabled and you had to look after it?

            /// 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_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/d/optout.
          • Nazri Ramliy
            ... Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from a litte memoization, perhaps expiring the cache whenever runtimepath is modified.
            Message 5 of 9 , Sep 11, 2014
            • 0 Attachment
              On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar <Bram@...> wrote:
              > Although removing arbitrary limits is good, making 'runtimepath' very
              > long is a bad idea. Every time Vim searches for a runtime file it will
              > visit those directories and request the contents.

              Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from a litte
              memoization, perhaps expiring the cache whenever 'runtimepath' is modified.

              > A plugin manager better use another mechanism. A dictionary to lookup
              > what file is located where is a LOT faster.

              Sorry for not researching this thoroughly, but isn't all what a plugin manager
              does is populate 'runtimepath' and then leave all the rest to vim?

              Nazri

              --
              --
              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/d/optout.
            • Bram Moolenaar
              ... That will very quickly get complicated. Esp. whenever changing runtime files. ... My startup time has drastically increased on a system where I started
              Message 6 of 9 , Sep 12, 2014
              • 0 Attachment
                Nazri Ramliy wrote:

                > On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar <Bram@...> wrote:
                > > Although removing arbitrary limits is good, making 'runtimepath' very
                > > long is a bad idea. Every time Vim searches for a runtime file it will
                > > visit those directories and request the contents.
                >
                > Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from a litte
                > memoization, perhaps expiring the cache whenever 'runtimepath' is modified.

                That will very quickly get complicated. Esp. whenever changing runtime
                files.

                > > A plugin manager better use another mechanism. A dictionary to lookup
                > > what file is located where is a LOT faster.
                >
                > Sorry for not researching this thoroughly, but isn't all what a plugin
                > manager does is populate 'runtimepath' and then leave all the rest to
                > vim?

                My startup time has drastically increased on a system where I started
                using a plugin manager. I have asked before how we can make this work
                better, probably by adding some code inside Vim.

                --
                I have a watch cat! Just break in and she'll watch.

                /// 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_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/d/optout.
              • Павлов Николай Алекса
                ... Currently most plugin managers work in one directory per plugin fashion. If they were more like other package managers (especially almost all system
                Message 7 of 9 , Sep 12, 2014
                • 0 Attachment
                  On September 12, 2014 1:46:51 PM GMT+03:00, Bram Moolenaar <Bram@...> wrote:
                  >
                  >Nazri Ramliy wrote:
                  >
                  >> On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar <Bram@...>
                  >wrote:
                  >> > Although removing arbitrary limits is good, making 'runtimepath'
                  >very
                  >> > long is a bad idea. Every time Vim searches for a runtime file it
                  >will
                  >> > visit those directories and request the contents.
                  >>
                  >> Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from
                  >a litte
                  >> memoization, perhaps expiring the cache whenever 'runtimepath' is
                  >modified.
                  >
                  >That will very quickly get complicated. Esp. whenever changing runtime
                  >files.
                  >
                  >> > A plugin manager better use another mechanism. A dictionary to
                  >lookup
                  >> > what file is located where is a LOT faster.
                  >>
                  >> Sorry for not researching this thoroughly, but isn't all what a
                  >plugin
                  >> manager does is populate 'runtimepath' and then leave all the rest to
                  >> vim?
                  >
                  >My startup time has drastically increased on a system where I started
                  >using a plugin manager. I have asked before how we can make this work
                  >better, probably by adding some code inside Vim.

                  Currently most plugin managers work in "one directory per plugin" fashion. If they were more like other package managers (especially almost all system ones) in "one directory per purpose" fashion (merged plugin trees in $HOME/.vim) it would solve the issue, but this is harder to code properly.

                  --
                  --
                  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/d/optout.
                • Bram Moolenaar
                  ... If it s a plugin script, not depending on a filetype, the plugin manager could put just one file under $VIMRUNTIME/plugin that sources the plugins from
                  Message 8 of 9 , Sep 12, 2014
                  • 0 Attachment
                    ZyX wrote:

                    > On September 12, 2014 1:46:51 PM GMT+03:00, Bram Moolenaar <Bram@...> wrote:
                    > >
                    > >Nazri Ramliy wrote:
                    > >
                    > >> On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar <Bram@...>
                    > >wrote:
                    > >> > Although removing arbitrary limits is good, making 'runtimepath'
                    > >very
                    > >> > long is a bad idea. Every time Vim searches for a runtime file it
                    > >will
                    > >> > visit those directories and request the contents.
                    > >>
                    > >> Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from
                    > >a litte
                    > >> memoization, perhaps expiring the cache whenever 'runtimepath' is
                    > >modified.
                    > >
                    > >That will very quickly get complicated. Esp. whenever changing runtime
                    > >files.
                    > >
                    > >> > A plugin manager better use another mechanism. A dictionary to
                    > >lookup
                    > >> > what file is located where is a LOT faster.
                    > >>
                    > >> Sorry for not researching this thoroughly, but isn't all what a
                    > >plugin
                    > >> manager does is populate 'runtimepath' and then leave all the rest to
                    > >> vim?
                    > >
                    > >My startup time has drastically increased on a system where I started
                    > >using a plugin manager. I have asked before how we can make this work
                    > >better, probably by adding some code inside Vim.
                    >
                    > Currently most plugin managers work in "one directory per plugin"
                    > fashion. If they were more like other package managers (especially
                    > almost all system ones) in "one directory per purpose" fashion (merged
                    > plugin trees in $HOME/.vim) it would solve the issue, but this is
                    > harder to code properly.

                    If it's a plugin script, not depending on a filetype, the plugin manager
                    could put just one file under $VIMRUNTIME/plugin that sources the
                    plugins from wherever they are located. Enabling/disabling a plugin
                    would then be uncommenting/commenting a line in that file.

                    Filetype plugins require a file with the name of the filetype. The
                    plugin manager could add just one directory, where the subdirectories
                    contain one-line files that source the plugin file from where it's
                    actually located. These files would be removed when disabling a plugin.

                    The extra indirection of sourcing another file is much less than the
                    effort Vim must do to search in directories in 'runtimepath'.

                    This way you can use git or something else to update the directory with
                    the plugin, while the plugin manager itself makes the connection between
                    the 'runtimepath' directory.

                    --
                    A: Because it messes up the order in which people normally read text.
                    Q: Why is top-posting such a bad thing?
                    A: Top-posting.
                    Q: What is the most annoying thing on usenet and in e-mail?

                    /// 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_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/d/optout.
                  • Shougo
                    Hi, I m neobundle s maintainar. ... Well, it is like pathogen feature. But I don t want to use the feature. Because, 1. plugin manager cannot disable plugins
                    Message 9 of 9 , Sep 13, 2014
                    • 0 Attachment
                      Hi, I'm neobundle's maintainar.

                      >Perhaps a new option would be better, 'runtimedir' - all directory found in
                      >there are regarded as individual runtimepath elements. This would make giant,
                      >unreadable 'runtimepath' values go away. glob() can help achieving
                      >deterministic addon loading order, so we can prefix the directory names in
                      >'runtimedir' with numbers to enforce ordering if necessary.

                      Well, it is like pathogen feature.
                      But I don't want to use the feature.

                      Because,
                      1. plugin manager cannot disable plugins in the directories.
                      2. plugin manager cannot change plugin loading order.
                      3. plugin manager cannot support lazy loading.


                      2014年9月13日土曜日 1時58分20秒 UTC+9 Bram Moolenaar:
                      > ZyX wrote:
                      >
                      >
                      >
                      > > On September 12, 2014 1:46:51 PM GMT+03:00, Bram Moolenaar <Bram@...> wrote:
                      >
                      > > >
                      >
                      > > >Nazri Ramliy wrote:
                      >
                      > > >
                      >
                      > > >> On Fri, Sep 12, 2014 at 5:04 AM, Bram Moolenaar <Bram@...>
                      >
                      > > >wrote:
                      >
                      > > >> > Although removing arbitrary limits is good, making 'runtimepath'
                      >
                      > > >very
                      >
                      > > >> > long is a bad idea. Every time Vim searches for a runtime file it
                      >
                      > > >will
                      >
                      > > >> > visit those directories and request the contents.
                      >
                      > > >>
                      >
                      > > >> Hmmm it seems that ex_cmds2.c:do_in_runtimepath() could benefit from
                      >
                      > > >a litte
                      >
                      > > >> memoization, perhaps expiring the cache whenever 'runtimepath' is
                      >
                      > > >modified.
                      >
                      > > >
                      >
                      > > >That will very quickly get complicated. Esp. whenever changing runtime
                      >
                      > > >files.
                      >
                      > > >
                      >
                      > > >> > A plugin manager better use another mechanism. A dictionary to
                      >
                      > > >lookup
                      >
                      > > >> > what file is located where is a LOT faster.
                      >
                      > > >>
                      >
                      > > >> Sorry for not researching this thoroughly, but isn't all what a
                      >
                      > > >plugin
                      >
                      > > >> manager does is populate 'runtimepath' and then leave all the rest to
                      >
                      > > >> vim?
                      >
                      > > >
                      >
                      > > >My startup time has drastically increased on a system where I started
                      >
                      > > >using a plugin manager. I have asked before how we can make this work
                      >
                      > > >better, probably by adding some code inside Vim.
                      >
                      > >
                      >
                      > > Currently most plugin managers work in "one directory per plugin"
                      >
                      > > fashion. If they were more like other package managers (especially
                      >
                      > > almost all system ones) in "one directory per purpose" fashion (merged
                      >
                      > > plugin trees in $HOME/.vim) it would solve the issue, but this is
                      >
                      > > harder to code properly.
                      >
                      >
                      >
                      > If it's a plugin script, not depending on a filetype, the plugin manager
                      >
                      > could put just one file under $VIMRUNTIME/plugin that sources the
                      >
                      > plugins from wherever they are located. Enabling/disabling a plugin
                      >
                      > would then be uncommenting/commenting a line in that file.
                      >
                      >
                      >
                      > Filetype plugins require a file with the name of the filetype. The
                      >
                      > plugin manager could add just one directory, where the subdirectories
                      >
                      > contain one-line files that source the plugin file from where it's
                      >
                      > actually located. These files would be removed when disabling a plugin.
                      >
                      >
                      >
                      > The extra indirection of sourcing another file is much less than the
                      >
                      > effort Vim must do to search in directories in 'runtimepath'.
                      >
                      >
                      >
                      > This way you can use git or something else to update the directory with
                      >
                      > the plugin, while the plugin manager itself makes the connection between
                      >
                      > the 'runtimepath' directory.

                      Yeh, it is so good! I want to support the feature in neobundle.

                      Questions:

                      1. Would you explain for autoload scripts in the feature?

                      2. The index files can be loaded when script loading?

                      3. Vim can load multiple index files in plugin directory or only one index file?

                      >
                      >
                      >
                      > --
                      >
                      > A: Because it messes up the order in which people normally read text.
                      >
                      > Q: Why is top-posting such a bad thing?
                      >
                      > A: Top-posting.
                      >
                      > Q: What is the most annoying thing on usenet and in e-mail?
                      >
                      >
                      >
                      > /// 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_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/d/optout.
                    Your message has been successfully submitted and would be delivered to recipients shortly.